Dissertacao

FUNDAÇÃO EDSON QUEIROZ
UNIVERSIDADE DE FORTALEZA – UNIFOR
SEMANTIC DATA SERVICES:

Uma abordagem para acesso e manipulação
de dados interligados
Hermano Albuquerque lira
FORTALEZA
2014
ii
FUNDAÇÃO EDSON QUEIROZ
UNIVERSIDADE DE FORTALEZA - UNIFOR
Hermano Albuquerque Lira
SEMANTIC DATA SERVICES — Uma abordagem para acesso e

manipulação de dados interligados
Dissertação apresentada ao curso de Mestrado em

Informática Aplicada da Universidade de
Fortaleza como parte dos requisitos necessários
para a obtenção do grau de Mestre em
Informática Aplicada.
Orientador: Prof. Dr. Pedro Porfírio Muniz Farias
FORTALEZA
2014
L768s Lira, Hermano Albuquerque.
Semantic data services: uma abordagem para acesso e manipulação de dados
interligados / Hermano Albuquerque Lira. - 2014.
117 f.
Dissertação (mestrado) – Universidade de Fortaleza, 2014.

“Orientação: Prof. Dr. Pedro Porfírio Muniz Farias.”
1. Web semântica. 2. Internet. 3. Interface homem-máquina. I. Farias, Pedro

Porfírio Muniz. II. Título.
CDU 681.3:004.822
v
“Suas crenças se tornam seus pensamentos

Seus pensamentos se tornam suas palavras
Suas palavras se tornam suas ações
Suas ações se tornam seus hábitos
Seus hábitos se tornam seus valores
Seus valores se tornam o seu destino.”
(Mahatma Gandhi)
Dedico este trabalho aos meus pais,

com muito amor.
vi
Agradecimentos
Acima de tudo, não poderia deixar de agradecer a Deus, que me dá saúde, coragem e
força de vontade para enfrentar os desafios da vida. Agradeço a ele por me permitir superar
todos os desafios que enfrentei ao longo nesta pesquisa e da minha vida.
Agradeço ao meu orientador, Prof. Pedro Porfírio, por sua inestimável orientação, dis-
ponibilidade, receptividade, além de muita paciência sempre que eu ficava meio “aperreado”.
Nossas reuniões sempre foram muito proveitosas, fornecendo todas as condições para que
meus estudos pudessem ser explorados eficientemente e direcionado à obtenção dos resulta-
dos que a pesquisa acadêmica exige.
Gostaria de expressar a minha gratidão aos professores da banca avaliadora, Angelo

Roncalli Alencar Brayner, Nabor das Chagas Mendonça e José Maria da Silva Monteiro Fi-
lho, pelo tempo dedicado à leitura e apreciação do meu trabalho.
Agradeço ao meu colega de mestrado e de trabalho José Renato, que muito me ajudou
e contribuiu com este trabalho, sua ajuda foi fundamental inúmeras vezes.
Agradeço a todos da equipe DE312 (da qual faço parte lá no SERPRO), pois todos
sempre foram muito generosos comigo e compreensíveis com minhas ausências no trabalho
em função das atividades do mestrado. Agradeço em especial ao meu chefe Marcelo, que
sempre me incentivou a entrar no mestrado, a crescer na carreira e me deu todo o suporte para
que fosse possível conciliar as atividades do trabalho e do mestrado.
Agradeço aos meus pais, por todos os sacrifícios enfrentados para promover a minha
educação, por sempre acreditarem em mim e incentivarem os meus estudos desde sempre.
Agradeço à Hayanne, minha recém-esposa, pelo seu apoio, paciência, amor e por abrir
mão da minha presença em muitas ocasiões, inclusive abrindo mão da nossa lua de mel, para
que eu utilizasse esse tempo para concluir a dissertação e entregá-la no prazo. A você meu
eterno amor e agradecimento. Prometo compensá-la em breve.
Por fim, agradeço ao SERPRO, empresa onde trabalho, pelo apoio financeiro e pela
minha inclusão no Programa de Incentivo à Pós-Graduação, o que possibilitou que eu fosse
liberado do trabalho parte do meu tempo para me dedicar a esta pesquisa.
vii
Resumo
Dados interligados (Linked Data) são dados disponibilizados na Web que adotam o
modelo RDF (Resource Description Framework) para representar suas estruturas, e a lingua-
gem OWL (Web Ontology Language) para atribuir uma semântica formal a essas estruturas.
Frequentemente tais dados podem ser acessados por serviços Web. Contudo, parte desses ser-
viços não permite o suporte à escrita. O que impossibilita a atualização das bases de dados dos
serviços. Mesmo nos serviços com suporte à escrita, são limitados ou inexistentes os meca-
nismos de verificação da integridade dos dados.
Neste trabalho, propomos os serviços de dados semânticos (Semantic Data Services –

SDS), uma abordagem para construção de serviços RESTful provedores de dados interligados
com suporte à escrita e a verificação de integridade. Essa abordagem adota a especificação
SERIN (Semantic RESTful Interface) para a construção de interfaces descritoras de serviços.
Tais interfaces definem que tipos de dados são providos e quais operações são permitidas so-
bre os dados.
Um diferencial do SDS é que, enquanto outras abordagens adotam a suposição de

mundo aberto, o SDS adota a suposição de mundo fechado localmente. Tipicamente, a supo-
sição de mundo aberto é caracterizada por possuir um domínio de conhecimento dos dados
que é sempre considerado incompleto. Isso implica que as bases de dados de abordagens ba-
seadas nessa suposição não possuem um esquema bem definido. Essa característica dificulta a
implementação de mecanismos de verificação de integridade dos dados. Por outro lado, a
abordagem SDS utiliza anotações definidas em sua interface que atuam como marcadores e
informam ao serviço SDS que tipos de dados devem ser interpretados segundo a suposição de
mundo fechado localmente. Isso permite definir formalmente que dados podem, ou não, ser
inseridos na base. É possível identificar dados incompletos ou inconsistentes de acordo com
regras de integridade definidas via essas anotações. De maneira geral, a abordagem SDS con-
tribui para delimitar com precisão o domínio de conhecimento de uma base de dados interli-
gados.
Palavras-chave: Serviços de acesso a dados; Dados interligados; interface SERIN; Verifica-

ção de restrições de integridade.
viii
Abstract
Linked Data is a kind of data that is available on the Web and adopt the Resource De-
scription Framework (RDF) model to represent their structures. Linked Data also adopts the
Web Ontology Language (OWL) to assign a formal semantics to these structures. Often such
data can be accessed by Web Services, such as the SPARQL Services, the Linked Data Ser-
vices (LIDS) and Linked Data Platform (LDP). However, not all of these approaches have
support to writing, what makes it impossible to update the databases in these services. Even in
the approaches that support writing, the data integrity checking mechanisms are limited, or
nonexistent.
In this work, we propose the Semantic Data Services (SDS), an approach to building
RESTful Data Services with writeable Linked Data support and integrity constraint check
support. This approach takes the RESTful Semantic Interface (SERIN) specification for build-
ing service descriptors. These interfaces define what type of data is provided and what opera-
tions are allowed on SDS services.
A key differentiator of SDS approach is that while other approaches adopt the Open
World Assumption (OWA), the SDS adopts the Local Closed World Assumption (LCWA).
For supporting LCWA, the SDS extended SERIN specification, adding a new set of annota-
tions that define integrity constraint rules on data.
A typical characteristic of OWA is that the domain of data is always considered in-
complete. This implies that the databases of services based on that assumption does not have a
well-defined schema. This characteristic makes it difficult to implement a data integrity con-
straint mechanism for such services. On the other hand, in the SDS approach, the new annota-
tions added in SERIN specification act as markers that tell to SDS service what types of data
should be interpreted according to the LCWA. Our approach allows defining which data may,
or may not, be inserted into the base. It is possible to identify incomplete or inconsistent data,
according to integrity rules defined via these new annotations. In general, the SDS approach
helps to establish the domain of knowledge in a RDF graph store.
Keywords: Data Services; Linked Data; SERIN; Integrity Constraint Check.

ix
Lista de Figuras
Figura 1: Diferença semântica entre a suposição de mundo aberto e de mundo fechado. ....... 16
Figura 2: Tipos de acesso a dados interligados. Figura adaptada de (AUER et al., 2010)....... 19
Figura 3: Relação entre especificações SPARQL. ................................................................... 20
Figura 4: Os recursos apresentados em cada host são instâncias de classes e podem ser
acessados por meio dos Serviços de Dados Semânticos que adotarem a interface SERIN
especificada. ............................................................................................................................. 33
Figura 5: Estrutura de uma tripla RDF. .................................................................................... 35
Figura 6: Uma instância utilizando diversas sintaxes, em (a) um objeto na UML, em (b) um
grafo RDF, em (c) uma representação RDF/XML e em (d) uma representação em Turtle. .... 35
Figura 7: Classes e propriedades de uma interface SERIN com suas anotações de operações
HTTP. ....................................................................................................................................... 40
Figura 8: Universidades A e B compartilhando a mesma interface SERIN. ............................ 41
Figura 9: Requisição HTTP GET para obter a lista de professores da Universidade A. .......... 41
Figura 10: Requisição HTTP POST e o retorno (código 201), indicando sucesso na criação da
nova instância. .......................................................................................................................... 43
Figura 11: Duas instâncias da classe “#Aluno”, uma com e a outra sem a propriedade
“#nome”. ................................................................................................................................... 50
Figura 12: Apenas uma relação P(x, y) é permitida para propriedades
InverseFunctionalProperty. ...................................................................................................... 52
Figura 13: Exemplo de alunos e suas matrículas. ..................................................................... 53
Figura 14: Dois hosts distintos mantendo dados de uma mesma pessoa.................................. 55
Figura 15: Interface SERIN com os conceitos "#Universidade", "#Professor" e suas
propriedades anotadas com NotNull e ForeignURI. ................................................................ 58
Figura 16: Propriedade #trabalha sem a anotação ForeignURI no cenário 1 e com a anotação
no cenário 2. ............................................................................................................................. 58
Figura 17: Dois serviços de dados semânticos compartilhando a mesma interface SERIN. ... 60
Figura 18: Possível ontologia para representar um comprovante de matrícula e suas entidades
correlatas................................................................................................................................... 64
x
Figura 19: O conjunto de instâncias que compõe um comprovante de matricula e a interface

SERIN que o define (As propriedades das classes “#Aluno” e “#Disciplina” foram ocultadas
da interface por motivo de clareza). ......................................................................................... 64
Figura 20: Requisição HTTP GET para uma instância com propriedades Embedded. ............ 65
Figura 21: Ontologia de um nota fiscal eletrônica com propriedades Embedded e classes
Internal. .................................................................................................................................... 68
Figura 22: Diagrama de implantação de um servidor SDS no servidor de aplicação JBoss 7. 73
Figura 23: Toda informação lida ou escrita na base de dados precisa respeitar o domínio de
conhecimento estabelecido na interface Universidade.owl. ..................................................... 74
Figura 24: Componentes do servidor SDS em um cenário de processamento de uma
requisição HTTP. ...................................................................................................................... 74
Figura 25: Diagrama de pacotes do servidor SDS.................................................................... 75
Figura 26: Componente Processador de Requisições com seus pacotes e principais classes. . 76
Figura 27: Diagrama de sequência de uma requisição HTTP GET sendo processada. ............ 76
Figura 28: Componente Verificador de Integridade de Dados com seus pacotes e principais
classes. ...................................................................................................................................... 77
Figura 29: Diagrama de sequência mostrando a troca de mensagens entre as duas principais
classes do componente Verificador de Integridade de Dados. ................................................ 78
Figura 30: Visão geral da arquitetura do framework Jena. ....................................................... 79
Figura 31: Componente Persistência com seu pacote e classe DB. ......................................... 80
Figura 32: Camada de persistência implementada via framework Jena e submódulos SDB ou
TDB. ......................................................................................................................................... 80
Figura 33: Ontologia de classificação das despesas do orçamento federal brasileiro. ............. 83
Figura 34: Serviço de dados semânticos implantado no host dados.gov.br. .................... 85
Figura 35: Serviços de dados semânticos implantados nos hosts dos órgãos do governo. ...... 85
Figura 36: Instância do aluno "#Hermano" apresentada graficamente. ................................... 95
xi
Lista de Tabelas
Tabela 1: Origens e destinos de voos. ...................................................................................... 16

Tabela 2: Convenção de endereçamento SERIN. ..................................................................... 38
Tabela 3: Relação entre as anotações e os tipos de propriedade. ............................................. 70
Tabela 4: Semântica padrão dos métodos HTTP...................................................................... 73
Tabela 5: Instância "#Hermano" representada em formato de tabela. ..................................... 98
Tabela 6: Comparação entre trabalhos relacionados. ............................................................. 100
Tabela 7: Diferenças entre SDS e SPARQL com relação às requisições HTTP. ................... 103
xii
Listagens
Listagem 1: Ontologia com uma restrição de cardinalidade definida. ..................................... 27

Listagem 2: Ontologia que define as anotações da especificação SERIN. .............................. 38
Listagem 3: Ontologia representando interface SERIN. .......................................................... 40
Listagem 4: Lista de professores retornada pela requisição HTTP GET. ................................ 42
Listagem 5: Requisição HTTP GET retorna um documento RDF como a instância "1" de
professor. .................................................................................................................................. 42
Listagem 6: Requisição HTTP DELETE para remoção da instância 1. ................................... 42
Listagem 7: Requisição POST com o corpo da requisição. ..................................................... 44
Listagem 8: Requisição HTTP PUT para atualização da propriedade "#CPF" da instância 5. 45
Listagem 9: Instância de professor com uma propridade "#trabalhaEm". ............................... 45
Listagem 10: Requisição PUT para adicionar duas propriedades "#trabalhaEm" à mesma
instância de professor. .............................................................................................................. 46
Listagem 11: Restrição de cardinalidade para a ontologia Aluno. ........................................... 50
Listagem 12: Propriedade “#nome” com anotação NotNull..................................................... 51
Listagem 13: Requisição HTTP POST para inserir uma instância de "#Aluno". .................... 51
Listagem 14 Propriedade #matricula com anotação Unique. ................................................... 53
Listagem 15: Requisição POST válida, desde que não haja outro aluno no host com a mesma
matrícula. .................................................................................................................................. 54
Listagem 16: Propriedade #CPF com anotação Id. .................................................................. 56
Listagem 17: Requisição POST para inserir uma instância da classe "#Professor". ................ 57
Listagem 18: Requisições HTTP não permitidas na ausência da anotação ForeignURI. ........ 59
Listagem 19: Comando HTTP DELETE permitido sobre a propriedade “#trabalha”. ............ 59
Listagem 20: Propriedade #trabalha anotada com ForeignURI e #endereco anotado com
NotNull. .................................................................................................................................... 59
Listagem 21: Axiomas de fechamento para as classes “#ProfessorServidor” e
“#ProfessorCeletista”................................................................................................................ 61
Listagem 22: Enumeração da classe Pais definida na interface SERIN. .................................. 62
Listagem 23: Exemplo de comprovante de matrícula gerado para o primeiro semestre de
2014. ......................................................................................................................................... 63
xiii
Listagem 24: Requisições HTTP GET necessárias para se obter todas as informações
relevantes de um comprovante de matrícula sem o auxílio da anotação Embedded. ............... 65
Listagem 25: Resposta a requisição HTTP GET. Sem a anotação Embedded, o RDF retornado
traria apenas a instância “#2014.1” (descrita nas linhas 3 a 10)............................................... 66
Listagem 26 Propriedade “#disciplinaMatriculada” com a anotação Embedded. .................... 67
Listagem 27: Requisições POST não permitidas, pois classes com anotação Internal não pode
ser instânciadas diretamente. .................................................................................................... 69
Listagem 28: Comando HTTP POST válido para criação de uma nova nota fiscal. ............... 69
Listagem 29 Coleção de instâncias do tipo People. ................................................................. 89
Listagem 30 Inserção de uma instância via HTTP POST. ....................................................... 90
Listagem 31: Interface LIDS descrita em formato RDF/N3 (Notation 3). ............................... 93
Listagem 32: Instância do aluno "#Hermano" em RDF/XML. ................................................ 95
Listagem 33: Retorno XML da consulta SPARQL para a instância "#Hermano". .................. 96
Listagem 34: Retorno JSON da consulta SPARQL para a instância "#Hermano". ................. 97
Listagem 35: Retorno CSV da consulta SPARQL para a instância "#Hermano". ................... 97
Listagem 36: Documento de descrição de serviço SPARQL. ................................................ 100
xiv
Sumário
Lista de Figuras ....................................................................................................................... ix
Lista de Tabelas ....................................................................................................................... xi
Listagens ..................................................................................................................................xii
1 Introdução ............................................................................................................................ 1
1.1 Motivação ................................................................................................................ 1
1.2 Objetivos .................................................................................................................. 5
1.3 Contribuições ........................................................................................................... 6
1.4 Estrutura da Dissertação .......................................................................................... 7
2 Dados Interligados ............................................................................................................... 8
2.1 Introdução ................................................................................................................ 8
2.2 Suposições Utilizadas nas Especificações dos Dados Interligados ......................... 9
2.2.1 Web Semântica ......................................................................................... 10
2.2.2 RDF ........................................................................................................... 11
2.2.3 Ontologia ................................................................................................... 11
2.2.4 Espécies de OWL ...................................................................................... 12
2.2.5 Lógica Descritiva ...................................................................................... 13
2.2.6 Suposições de Mundo Aberto e de Mundo Fechado................................. 14
2.2.7 Suposição de Nome Único ........................................................................ 17
2.2.8 Suposição de Mundo Fechado Localmente .............................................. 18
2.3 Tipos de acesso a dados interligados ..................................................................... 19
2.3.1 Serviços de acesso por consulta ................................................................ 20
2.3.2 Serviços de acesso por Dump.................................................................... 21
2.3.3 Serviços de acesso em nível de entidade .................................................. 21
2.4 Suporte à escrita para dados interligados............................................................... 23

xv
2.5 Verificação da integridade semântica .................................................................... 25
2.6 Integração entre abordagens de suporte à escrita e verificação de integridade ..... 28
2.7 Sumário .................................................................................................................. 29
3 Serviços de Dados Semânticos .......................................................................................... 30
3.1 Introdução .............................................................................................................. 30
3.2 Usando URIs para Acessar Dados Interligados ..................................................... 31
3.3 Interface Semântica RESTful ................................................................................ 32
3.3.1 Separação do Conhecimento ..................................................................... 33
3.3.2 Instância RDF: Uma unidade de recuperação de informação ................... 34
3.3.3 Integridade Semântica ............................................................................... 36
3.3.4 Anotações para manipulação dos dados .................................................... 37
3.3.5 Convenção de Endereçamento .................................................................. 38
3.4 Cenário de Uso ...................................................................................................... 39
3.5 Sumário .................................................................................................................. 46
4 Restrições de Integridade na Interface SERIN ............................................................... 47
4.1 Introdução .............................................................................................................. 47
4.2 Restrições integridade via interface SERIN .......................................................... 48
4.3 Anotações para restrição de integridade ................................................................ 49
4.3.1 Anotação NotNull ...................................................................................... 49
4.3.2 Anotação Unique....................................................................................... 51
4.3.3 Anotação Id ............................................................................................... 54
4.3.4 Anotação ForeignURI ............................................................................... 57
4.3.5 Anotação Embedded ................................................................................. 63
4.3.6 Anotação Internal ..................................................................................... 67
4.3.7 Escopo das anotações ................................................................................ 70
4.4 Sumário .................................................................................................................. 70
5 Uma arquitetura para serviços de dados semânticos ..................................................... 71

xvi
5.1 Introdução .............................................................................................................. 71
5.2 Estrutura Arquitetural ............................................................................................ 72
5.2.1 Componente Processador de Requisições ................................................ 75
5.2.2 Componente Verificador de integridade de dados ................................... 77
5.2.3 Componente Persistência ......................................................................... 78
5.3 Um cenário para o uso do SDS .............................................................................. 81
5.4 Exemplo de uso do SDS ........................................................................................ 83
5.5 Sumário .................................................................................................................. 86
6 Análise Comparativa com os Serviços de Dados Semânticos ........................................ 87
6.1 Introdução .............................................................................................................. 87
6.2 Metodologia ........................................................................................................... 87
6.3 Open Data Protocol (OData)................................................................................. 88
6.3.1 Suporte ao modelo de dados RDF............................................................. 88
6.3.2 Suporte à escrita ........................................................................................ 90
6.3.3 Suporte à verificação de integridade ......................................................... 91
6.3.4 Interface descritora de serviço .................................................................. 91
6.4 Linked Data Services (LIDS)................................................................................. 91
6.5 Linked Data Platform (LDP) ................................................................................. 93
6.6 SPARQL 1.1 Protocol ........................................................................................... 94

xvii
6.7 Comparação entre Serviços de Acesso a Dados .................................................. 100
6.7.1 Suporte ao modelo de dados RDF........................................................... 101
6.7.2 Suporte à escrita ...................................................................................... 102
6.7.3 Suporte à verificação de integridade ....................................................... 103
6.7.4 Interface descritora de serviço ................................................................ 105
6.8 Sumário ................................................................................................................ 107
7 Conclusão .......................................................................................................................... 108
7.1 Conclusões ........................................................................................................... 108
7.2 Considerações Finais ........................................................................................... 109
7.3 Limitações de Escopo e Trabalhos Futuros ......................................................... 109
Referências Bibliográficas ................................................................................................... 111

Capítulo 1
1
Introdução
Este capítulo apresenta a motivação, o objetivo, as contribuições e a organização da

dissertação.
1.1 Motivação
A localização, o acesso, a manipulação e a integração de dados no ambiente Web re-

presentam importantes desafios, sobretudo, em razão da vasta quantidade de dados que esse
ambiente disponibiliza. De acordo com o site WorldWildWebSize1 as principais ferramentas
de busca possuem atualmente cerca de 1,37 bilhões de páginas indexadas. Uma parte expres-
siva desses dados está representada de forma desestruturada.
Nesse contexto, os dados interligados — Linked Data (BIZER; HEATH; BERNERS-

LEE, 2009) — estão se tornando um importante mecanismo para expor dados estruturados de
maneira que esses possam ser utilizados por máquinas para automação, integração e reuso
entre diferentes aplicações. De acordo com Tim Berners-Lee, a Web semântica é a extensão
da Web atual na qual é atribuído significado bem-definido para a informação, permitindo que
computadores e pessoas trabalhem em cooperação (BERNERS-LEE; HENDLER; LASSILA,
2001).
A disponibilização dos dados interligados na Web está crescendo bastante, impulsio-

nada, principalmente, pelo projeto de dados abertos interligados (Linking Open Data Project2)
e iniciativas de vários países para publicar dados do setor público. A capacidade de interligar
fontes de dados de diferentes hosts, que utilizam os mesmos vocabulários e modelo de dados,
abre novas possibilidades para a forma como esses dados podem ser usados.
1
http://www.worldwidewebsize.com
2
http://linkeddata.org
2
No ambiente Web, tanto servidores quanto serviços Web operam sobre o protocolo
HTTP. No entanto, pouco deles expõem seus dados como dados interligados e os que expõem
nem sempre possuem suporte à escrita. Além disso, entre as soluções que possuem algum
suporte à escrita, são raros os que possuem mecanismos de verificação de integridade de da-
dos de acordo com a suposição de mundo fechado. A adoção da suposição de mundo fechado
permite que um serviço interprete sua base de dados como um mundo fechado e isso é bastan-
te útil quando essa base pode ser considerada completa. A interpretação dos dados interliga-
dos de uma base segundo a suposição de mundo fechado oferece algumas garantias de inte-
gridade para os dados que não pode ser obtida a partir da suposição de mundo aberto, mais
tradicionalmente utilizada para os dados interligados.
Neste estudo, serão analisados dois problemas: 1) a falta de suporte à escrita nos servi-
ços Web e 2) a falta de um mecanismo de verificação de integridade de dados aderente à su-
posição de mundo fechado. A partir desses problemas, objetiva-se propor uma especificação
para serviços Web que permita a leitura e a escrita de dados interligados, por meio de serviços
RESTful (RICHARDSON; RUBY, 2007), e possua um mecanismo de integridade dos dados.
Sobre a falta de suporte à escrita, Coppens (COPPENS et al., 2012) declara que as
abordagens atuais para a publicação de dados estruturados na Web geralmente oferecem inter-
faces de leitura/consulta para os dados subjacentes. Coppens também argumenta que a Web
começou como uma versão somente de leitura (i.e. Web 1.0), evoluiu para uma Web de leitura
e escrita, onde os seres humanos podem colaborar (i.e. Web 2.0), e é atualmente uma Web que
adota tecnologias semânticas para que agentes de software possam ler e interpretar os dados
subjacentes (i.e. Web 3.0). Assim, Coppens conclui que dada essa linha de evolução, o próxi-
mo passo lógico para uma Web 4.0 parece ser uma Web semântica de leitura e escrita, onde os
agentes possam colaborar.
De acordo com (LANTHALER; GUTL, 2011a), muitos hosts optam por disponibilizar
seus dados através de serviços Web alinhados ao estilo arquitetural REST — Representational
State Transfer — (FIELDING, 2000), porém tais serviços não costumam se beneficiar das
vantagens dos dados interligados. Uma das razões para isso é a falta de suporte à escrita para
os dados interligados. Ao passo que os serviços Web RESTful promovem uma interface de
leitura e escrita para os dados subjacentes. Dessa forma, a combinação de serviços RESTful e
da Web semântica pode trazer vários benefícios ao acesso e à manipulação dos dados interli-
gados. Enquanto os dados interligados oferecem um conjunto de melhores práticas para a pu-
3
blicação e vinculação de dados estruturados na Web, os serviços RESTful estabelecem as re-

gras para a leitura e escrita desses dados pelos agentes de software.
Tanto o modelo RDF — Resource Description Framework — (MANOLA; MILLER,

2004), proposto pelo World Wide Web Consortium3 (W3C) para representação dos dados in-
terligados, quanto os serviços Web RESTful são baseados na arquitetura da Web (JACOBS;
WALSH, 2004). Assim as duas tecnologias possuem um forte alinhamento arquitetural. No
entanto as duas tecnologias raramente são utilizadas em conjunto. Apesar de parecer natural
combinar seus pontos fortes, os esforços atuais a fim de proporcionar acesso a dados, implan-
tam endpoints SPARQL — SPARQL Protocol and RDF Query Language — (HARRIS;
SEABORNE, 2013), ou simplesmente publicam dados estáticos, em vez de fornecer dados
interligados por meio de serviços Web RESTful. Alguns exemplos de endpoints SPARQL
são: a especificação SPARQL 1.1 Protocol (FEIGENBAUM et al., 2013) e a extensão à lin-
guagem SPARQL proposta por (WILDE; HAUSENBLAS, 2009). Page (PAGE; DE ROURE;
MARTINEZ, 2011) argumenta que, apesar de SPARQL ser a interface de consulta padrão
para RDF, a maioria dos endpoints SPARQL é implementada, e usada, no estilo RPC (Remote
Procedure Call). Lanthaler (LANTHALER; GUTL, 2011a) afirma que assim como os end-
points SQL são raros hoje em dia, não se espera que endpoints SPARQL sejam muito difun-
didos em um futuro próximo. Isso porque é consideravelmente mais caro expor endpoints
SQL ou SPARQL ao invés de interfaces de serviços RESTful.
Várias pesquisas, e.g. (LANTHALER; GUTL, 2011a), têm sido conduzidas com foco
na especificação de serviços Web RESTful com suporte à leitura e à escrita de dados interli-
gados. Tais pesquisas focam no alinhamento natural entre o modelo de dados RDF e o estilo
arquitetural REST e especificam Web APIs 4 , ao invés de endpoints SPARQL, como uma
abordagem mais adequada para o estabelecimento de comunicação entre clientes e serviços.
Para os serviços Web centrados em dados interligados, a interface de serviço deve de-
sempenhar dois papeis: 1) descrever quais são os tipos de dados providos pelo serviço e 2)
quais são as operações que podem ser feitas sobre esses dados. É desejável a utilização da
linguagem OWL — Web Ontology Language — (SMITH; WELTY; MCGUINNESS, 2004)
para descrever a interface de serviço. Também é desejável que a linguagem OWL codifique as
restrições de integridade que devem ser satisfeitas pelas instâncias dos dados.
3
http://www.w3.org
4
O termo Web API surgiu como o nome coletivo para os serviços Web RESTful, a fim de distingui-los
dos serviços Web baseados em SOAP.
4
A linguagem OWL, em sua especificação corrente, adota a suposição de mundo aber-

to, ou Open Word Assumption (OWA), e não adota a suposição de nome único, Unique Name
Assumption (UNA), enquanto os bancos de dados relacionais adotam a suposição de mundo
fechado, Closed World Assumption (CWA), e nomes únicos. A principal distinção entre as
duas suposições é que as condições que desencadeiam violações de integridade de dados em
sistemas aderentes à suposição de mundo fechado, irão gerar novas inferências nos dados de
sistemas baseados na suposição de mundo aberto.
Sobre os esforços atualmente feitos para conciliar as diferenças da suposição do mun-

do fechado e de mundo aberto em serviços Web que trabalham com dados interligados, vários
autores propõem estratégias para estender a linguagem OWL, adicionando mecanismos que
suportem a suposição de mundo fechado. Motik (MOTIK; HORROCKS; SATTLER, 2007),
por exemplo, afirma que ontologias codificadas em OWL são interpretadas como bases de
dados incompletas, no entanto, muitas bases encontradas na prática são completas. Assim,
para tornar a linguagem OWL mais flexível, Motik propõe uma abordagem que permite con-
trolar explicitamente o grau de incompletude por meio de restrições de integridade. Já Kris-
nadhi (KRISNADHI; SENGUPTA; HITZLER, 2011) enfatiza que o uso da suposição de
mundo fechado na linguagem OWL é aplicável, por exemplo, quando os dados são recupera-
dos de um banco de dados, ou se os dados de outra forma podem ser considerados completos
no que diz respeito à aplicação em questão. Como consequência dos esforços feitos para com-
binar a OWA e a CWA na modelagem das tecnologias da Web semântica, alguns autores de-
finem que as linguagens de representação do conhecimento que possuem ambos os recursos
da OWA e da CWA são ditas aderentes à suposição de mundo fechado localmente, Local
Closed World Assumption (LCWA) (KNORR; ALFERES; HITZLER, 2011; KRISNADHI;
SENGUPTA; HITZLER, 2011).
Este trabalho propõe uma especificação, intitulada Serviço de Dados Semânticos

(SDS), para construção de serviços Web RESTful com capacidade de manipulação (leitura e
escrita) de dados interligados e com um mecanismo de verificação de integridade aderente à
suposição de mundo fechado localmente (no host).
Elementos arquiteturais tipicamente encontrados em serviços Web são: a interface de

serviço, o modelo de representação de dados e o protocolo de comunicação. Nesta proposta a
especificação SERIN (MUNIZ et al., 2011) será utilizada para a construção das interfaces de
serviço, além disso, o modelo de dados RDF será adotado para a representação dos dados in-
5
terligados, bem como o protocolo HTTP será utilizado para prover a comunicação entre clien-
tes e hosts de serviços.
A especificação do SDS é, assim, a primeira contribuição deste trabalho. Outra contri-

buição proposta aqui é a adição de um conjunto de anotações à especificação SERIN. Por
meio dessas anotações será possível adotar a suposição de mundo fechado localmente nos
hosts SERIN. A combinação desses dois aspectos permite que agentes de software possam
inserir ou atualizar dados interligados mantidos nos hosts, além disso, com a adoção da supo-
sição de mundo fechado localmente, o host adquire um mecanismo que provê garantias para
consistência e completude dos dados.
Este estudo propõe o uso de uma especificação simples — os serviços de dados se-
mânticos — para a manipulação de dados interligados e ao mesmo tempo ideal para utilização
conjunta com as bases de dados legadas. Essas características justificam essa pesquisa, por
tratar algumas limitações existentes nos serviços de dados atuais, como será apresentado ao
longo deste trabalho.
1.2 Objetivos
Este trabalho tem como objetivo geral definir uma abordagem para especificar servi-
ços Web RESTful aderentes a especificação SERIN (MUNIZ et al., 2011) e com suporte à
escrita de dados interligados.
Os objetivos específicos a serem alcançados com essa abordagem são:
 Especificar um tipo de serviço Web de acesso a dados chamado Serviço de Dados

Semânticos, capaz de ler a escrever dados interligados.
 Estender a especificação SERIN, adicionando novas anotações para prover a veri-
ficação de integridade de dados de acordo com a suposição de mundo fechado lo-
calmente.
 Projetar e implementar uma arquitetura inicial, do Serviço de Dados Semânticos.
 Avaliar a solução proposta.
6
1.3 Contribuições
A primeira contribuição deste estudo é a extensão de especificação SERIN. Um novo

conjunto de anotações foi incorporado à ontologia SERIN, o que permitiu que os dados inter-
ligados descritos pela interface pudessem ser interpretados de acordo com a suposição de
mundo fechado localmente. Essas anotações têm a finalidade de detectar violações de integri-
dade nos dados que são escritos por meio do serviço. Isso contribui para facilitar a integração
dos dados interligados com os bancos relacionais e oferecer garantias de consistência e com-
pletude sobre os dados.
A segunda contribuição é a definição de uma arquitetura que implementa os serviços

de dados interligados. Um elemento chave para essa arquitetura é a utilização das interfaces
SERIN, pois essas interfaces proveem uma camada de interoperabilidade de dados entre fon-
tes de dados heterogêneas. Além disso, suas descrições semânticas em formato OWL são fa-
cilmente processáveis por máquinas. Assim, essa arquitetura promove por meio das interfaces
SERIN uma abordagem adequada para a navegação de dados por agentes de software, contri-
buindo para a internet das coisas, assim como para a promoção da integração de múltiplas
fontes de dados.
A terceira contribuição é a construção de um framework inicial que implementa a ar-

quitetura proposta. O referido framework demonstra, de forma prática, a manipulação de da-
dos interligados por meio de um serviço RESTful. O framework é utilizado para fornecer
exemplos de uso dos serviços de dados interligados.
A quarta contribuição é a definição do conceito de Instância RDF. Os serviços de da-

dos semânticos expõem os dados armazenados em seus hosts como instâncias RDF. Tais ins-
tâncias são trocadas entre o SDS e seus clientes por meio de documentos RDF válidos, con-
tendo uma ou mais instâncias.
O conceito de instância proposto promove uma visão análoga a de um objeto no para-

digma da orientação a objetos. Assim, uma instância RDF é o conjunto de triplas necessário
para representar uma instância de uma classe pertencente a uma interface SERIN. Todas as
triplas de uma instância RDF compartilham o mesmo nó sujeito. Portanto, toda instância é
identificável pela URI (Uniform Resource Identifier) (BERNERS-LEE; FIELDING;
MASINTER, 2005) do sujeito das triplas que a compõe. Além disso, anotações presentes nas
7
classes e propriedades da interface indicam restrições que devem ser atendidas para que o
conjunto de triplas possa ser considerado uma instância. Portanto nem sempre um conjunto de
triplas com o mesmo sujeito constitui uma instância RDF.
1.4 Estrutura da Dissertação
Além desta introdução, a dissertação está organizada em mais seis capítulos, descritos
a seguir.
O capítulo 2 introduz os conceitos e tecnologias associadas aos dados interligados.
O capítulo 3 apresenta os serviços de dados semânticos (SDS), sua relação com a in-
terface SERIN e explica os conceitos associados a essa interface.
O capítulo 4 apresenta o mecanismo proposto de verificação de restrições de integri-

dade dos serviços de dados semânticos.
O capítulo 5 descreve uma proposta de arquitetura para os serviços de dados semânti-

cos e mostra exemplos de aplicações da arquitetura proposta.
O capítulo 6 apresenta uma comparação do presente estudo com outros serviços de

acesso a dados.
O capítulo 7 reúne as conclusões e propostas para estudos futuros.

Capítulo 2
2
Dados Interligados
Este capítulo apresenta o conceito de dados interligados e as tecnologias que permi-

tem o acesso a eles. Também justifica a importância do suporte à escrita e da verificação de
integridade de dados nos moldes da suposição de mundo fechado localmente.
2.1 Introdução
O termo “Dados Interligados” — Linked Data (HEATH; BIZER, 2011) — refere-se a

um conjunto de melhores práticas para publicar e conectar dados estruturados na Web. Essas
práticas foram introduzidas por Tim Berners-Lee em (BERNERS-LEE, 2006) e resumem-se
em quatro princípios básicos:
1. Usar URIs como nome para recursos;

2. Usar URIs HTTP para que as pessoas possam encontrar esses nomes;
3. Quando alguém procura por uma URI, garantir que informações úteis possam ser
obtidas por meio dessa URI, as quais devem estar representadas em um modelo
padrão;
4. Incluir links para outras URIs de forma que outros recursos possam ser descober-
tos.
O primeiro princípio declara o uso de referências URI para identificar, não apenas do-
cumentos Web e conteúdos digitais, mas também objetos do mundo real e conceitos abstratos.
O segundo princípio declara o uso de URIs como URLs para endereçar os objetos e os concei-
tos abstratos definidos pelo princípio anterior, possibilitando que por meio dessas URLs os
recursos sejam recuperados via o protocolo HTTP. O terceiro princípio declara o uso do pa-
drão RDF (MANOLA; MILLER, 2004) como modelo padrão para os dados interligados e o
quarto princípio diz respeito ao uso de hiperlinks para conectar não apenas os documentos da
Web, mas qualquer tipo de recurso.
9
Os dados interligados permitem que as informações sejam representadas com uma se-
mântica explícita e formal, facilitando, assim, seu compartilhamento, reuso e processamento
por sistemas de software. Abordagens tradicionais para representação de dados, como o XML
(BRAY et al., 2008), atacam o problema em um nível estrutural ou sintático e dependem for-
temente de padronização de um conjunto predeterminado de esquemas de representação dos
dados. De acordo com o World Wide Web Consortium (W3C), para tornar a Web de Dados
interligados uma realidade, é importante que uma grande quantidade de dados esteja disponí-
vel na Web em um modelo padrão, interpretável por agentes de software e gerenciável medi-
ante as ferramentas da Web semântica.
As vantagens da criação de uma visão de dados interligados para os dados na Web po-
dem ser resumidas com base nas tarefas que facilitam:
 Integração: dados em diferentes hosts pode ser integrados utilizando semântica e

mecanismos do RDF, e neste sentido, a Web de dados pode ser imaginada como
uma grande base de dados (HEATH; BIZER, 2011).
 Recuperação: uma vez que os dados estão publicados na Web de dados, as consul-
tas podem se estender por diferentes hosts e métodos de recuperação mais podero-
sos podem ser construídos.
A necessidade de mecanismos provedores de dados interligados na Web, e as similari-

dades entre o estilo arquitetural REST (FIELDING, 2000) e o modelo RDF têm gerado várias
pesquisas (LANTHALER; GÜTL, 2012; SPEISER; HARTH, 2011; VERBORGH et al.,
2012) com o intuito de especificar serviços RESTful de acesso a dados interligados. O propó-
sito deste capítulo, portanto, é apresentar os conceitos e tecnologias associados aos dados in-
terligados, além de motivar a importância do suporte à escrita, e a importância de um meca-
nismo de verificação de integridade que suporte a suposição de mundo fechado localmente.
2.2 Suposições Utilizadas nas Especificações dos Dados In-

terligados
A World Wide Web alterou radicalmente a forma de se compartilhar dados, diminuin-

do as barreiras para a publicação e para o acesso a documentos dos mais variados assuntos.
Além disso, os links de hipertexto dispostos nesses documentos permitiram às pessoas nave-
10
gar através dos documentos, encontrando outros documentos de assuntos relacionados. A Web
é uma rede de documentos interconectados de natureza genérica, aberta e extensível
(JACOBS; WALSH, 2004), e são justamente esses princípios os elementos-chave para o seu
crescimento irrestrito.
Contudo, apesar dos benefícios citados, até recentemente os mesmos princípios que
permitiram que a Web de documentos se desenvolvesse não tinham sido aplicados aos dados.
Tradicionalmente, os dados publicados na Web eram disponibilizados em formatos como
CSV ou XML, ou descritos em tabelas HTML, sacrificando muito de sua estrutura e semânti-
ca. Adicionalmente, a semântica convencional de um link entre documentos é implícita e in-
formal, assim como o formato HTML não é suficientemente expressivo para descrever dados
como uma entidade individual.
No entanto, nos últimos anos, a Web evoluiu de uma rede de documentos interligados
para uma rede de documentos e dados interligados. A razão para essa evolução está em um
conjunto de melhores práticas para a publicação e conexão de dados estruturados na Web.
Essas melhores práticas ficaram conhecidas pelos termos Linked Data ou Web semântica. De
acordo com o criador desses termos, Tim Berners-Lee, a Web Semântica é uma rede de dados
que podem ser processados diretamente ou indiretamente por máquinas (BERNERS-LEE,
1999). Assim, baseado nessa definição, os dois termos serão tratados neste trabalho como
sinônimos.
2.2.1 Web Semântica
De acordo com o W3C5, a Web semântica provê um arcabouço comum que permite
que dados sejam compartilhados e reutilizados através das interfaces de aplicações empresari-
ais e comunitárias. É um esforço colaborativo liderado pelo W3C com a participação de um
grande número de pesquisadores e parceiros da indústria. Baseia-se no Resource Description
Framework (RDF).
5
http://www.w3.org/2001/sw/
11
2.2.2 RDF
RDF (MANOLA; MILLER, 2004) é um modelo padrão para o intercâmbio de dados

na Web. O RDF tem características que facilitam a integração de dados, pois ele estende a
estrutura de links da Web utilizando URIs para nomear as relações entre os recursos, bem co-
mo para nomear os próprios recursos. O modelo RDF permite, portanto, que dados estrutura-
dos e semiestruturados possam ser integrados, expostos e compartilhados entre diferentes
aplicações de maneira homogênea. Esta estrutura de recursos (ou dados) interligados forma
um grafo direcionado, onde os links representam as arestas que ligam dois recursos e cada
recurso representa um vértice do grafo. Essa estrutura é comumente referenciada como tripla.
Uma importante característica do modelo RDF é poder expressar formal e explicita-

mente a semântica de seus dados. Isso é feito por meio de conjuntos de vocabulários definidos
em ontologias e que se integram ao grafo RDF nomeando seus links (ou arestas). Todo link é,
portanto, nomeado (ou tipado).
2.2.3 Ontologia
A comunidade de Inteligência Artificial adota como definição de ontologia aquela

proposta por (GRUBER, 1993), em que “ontologia é uma especificação formal de uma con-
ceitualização”. Outra definição amplamente aceita na comunidade é a de Fensel (FENSEL,
2003) que estende a de Gruber ao afirmar que “ontologia é uma especificação explícita e for-
mal de uma conceitualização compartilhada”.
Conceitualização refere-se a um modelo abstrato de algum fenômeno que identifica os

conceitos relevantes desse fenômeno. Explícita significa que os tipos de conceitos utilizados e
as restrições no seu uso são explicitamente definidos. Formal refere-se ao fato de que a onto-
logia deve se representada sob uma linguagem legível por sistemas de software. Comparti-
lhada reflete a noção de que uma ontologia representa o conhecimento consensual de um do-
mínio (FENSEL, 2003). Uma ontologia define, portanto, um vocabulário comum acerca de
um domínio utilizado para descrever dados que precisam ser compartilhados.
A Web Ontology Language — OWL (SMITH; WELTY; MCGUINNESS, 2004) — é

uma família de linguagens de representação de conhecimento. Essas linguagens são caracteri-
zadas pela semântica formal utilizada para descrever os dados da Web Semântica. OWL é
12
endossado pelo World Wide Web Consortium (W3C) e tem atraído interesses tanto do meio
acadêmico, como comercial. Ela inclui definições interpretáveis por máquina de conceitos
básicos em um domínio e as relações entre eles. Entre os benefícios de sua utilização desta-
cam-se: o compartilhamento de um entendimento comum de estruturas de dados entre agentes
de software, a reutilização do conhecimento de um domínio e a separação entre o conheci-
mento do domínio do conhecimento operacional.
2.2.4 Tipos de OWL
A primeira versão da especificação OWL (SMITH; WELTY; MCGUINNESS, 2004)

fornecia três tipos, ou sub-linguagens, com níveis crescentes de expressividade, projetadas
para serem utilizadas por comunidades específicas de implementadores e usuários. São elas:
 OWL Lite: Projetada para aqueles usuários que necessitam primariamente de uma
hierarquia de classificação e características de restrição simples. Por exemplo, a
OWL Lite suporta restrições de cardinalidade, mas somente permite valores de
cardinalidade de 0 ou 1;
 OWL DL: Projetada para aqueles usuários que precisam de expressividade
máxima sem perda de completude computacional, i.e., garantia de que todas as in-
ferências serão computadas, e decidibilidade, todas as computações terminarão em
tempo finito. Essa sub-linguagem inclui todos os construtores da linguagem OWL,
porém, com restrições tais como a separação de tipos, i.e., uma classe não pode ser
também um indivíduo ou propriedade. Em outras palavras, classes, indivíduos e
propriedades formam conjuntos disjuntos e consequentemente uma classe sim-
plesmente denota um conjunto de indivíduos, mas não pode ser ela mesma um in-
divíduo. O termo “DL”, acrônimo para Description Logic, presente no nome dessa
sub-linguagem, refere-se a sua correspondência com a lógica descritiva, um campo
de pesquisa que tem estudado um fragmento decidível de lógica de primeira or-
dem;
 OWL Full: Destinada aos usuários que desejam máxima expressividade e a liber-
dade sintática do RDF, mas sem as garantias computacionais de completude e de-
cidibilidade previstas na OWL DL. Por exemplo, é possível que uma classe possa
ser tratada simultaneamente como uma coleção de indivíduos e como um indiví-
duo propriamente dito. Outra diferença significativa em relação à OWL DL é que
13
uma propriedade do tipo owl:DatatypeProperty pode ser marcada como uma

owl:InverseFunctionalProperty. Diferentemente das sub-linguagens anteriores, a
OWL Full permite estender o significado dos termos predefinidos nos vocabulários
OWL (BECHHOFER et al., 2004) e RDF (KLYNE; CARROLL, 2004). Contudo,
é improvável que qualquer software de raciocínio seja capaz de suportar todas as
funcionalidades dessa linguagem.
A segunda versão do OWL (HITZLER et al., 2012) enfatizou a importância de se de-

finir fragmentos não apenas decidíveis, mas tratáveis em tempo polinomial. Assim, a OWL 2
estendeu o conjunto de sub-linguagens em sua especificação. A partir dessa segunda verão o
termo sub-linguagem foi substituído por perfil, enfatizando a ideia de que cada perfil da OWL
é mais adequado para um tipo diferente cenário de aplicação.
Para o propósito deste trabalho, a OWL DL é a que oferece o conjunto de característi-

cas mais interessantes. Dentre essas características destacam-se a expressividade máxima sem
perda de completude computacional, a decidibilidade e o provimento explícito de tipos (Pro-
vide Explicit Typing) (BECHHOFER et al., 2004). Essa última característica determina que
todo recurso deve ter seu tipo declarado explicitamente. Por exemplo, se a URI do recurso X é
utilizada onde se espera uma classe, então o grafo RDF deve conter uma tripla afirmando que
X rdf:type owl:Class (X é uma Classe). Os benefícios da OWL DL para este trabalho ficarão
mais claros nos próximos capítulos.
2.2.5 Lógica Descritiva
A lógica descritiva (BAADER et al., 2003) compõe uma família de formalismos para
representação do conhecimento. Ela modela conceitos, papéis, indivíduos e seus relaciona-
mentos; sendo comumente utilizada para representar formalmente taxonomias de um domínio.
Por essa razão, em 2004 foi adotada como base para a linguagem OWL.
Formalmente, uma base de conhecimento de lógica descritiva é um par К = (Τ, Α), on-
de Τ é um TBox (Terminological Box) e Α é um ABox (Assertional Box). De forma geral, o
TBox representa sentenças descrevendo conceitos, papeis e suas relações, i.e, descrevendo as
noções relevantes de um domínio de aplicação, enquanto que o ABox representa sentenças
que expressam as relações entre os indivíduos e seus conceitos e papeis, i.e., descreve uma
situação concreta, afirmando propriedades a cerca dos indivíduos.
14
Por exemplo, a declaração:
(1) Todo funcionário é uma pessoa
pertence ao TBox, enquanto que a declaração:
(2) Pedro é um funcionário
pertence ao ABox.
Em princípio, a distinção entre TBox e ABox não é significativa, no sentido de que os

dois tipos de sentenças não são tratados de formas diferentes na lógica de primeira ordem.
Contudo, essa distinção pode ser adequada para descrever e formular procedimentos de deci-
são em linguagens baseadas em lógica descritiva. Por exemplo, a complexidade das declara-
ções TBox podem afetar bastante o desempenho de máquinas de inferência para determinados
procedimentos, independentemente das declarações ABox. Assim, é útil ter uma maneira de
processar partes específicas da base de conhecimento. Outro motivo que justifica a distinção
entre TBox e ABox é do ponto de vista do projetista da ontologia, pois, é útil distinguir entre
as declarações que descrevem os conceitos do mundo (axiomas TBox) e as manifestações
particulares (ou instâncias) desses conceitos (declarações ABox).
Outras duas características típicas da lógica descritiva, e que não são compartilhadas
pela maioria dos outros formalismos de descrição de dados, são a ausência da suposição de
nomes únicos (Unique Name Assumption — UNA) e a suposição de mundo aberto (Open
World Assumption — OWA). Isso contrasta bastante com outro formalismo bastante utilizado
para descrição de dados, o modelo relacional, que é baseado na suposição de mundo fechado
(Closed World Assumption — CWA) e admite a UNA. Essas suposições serão apresentadas
em mais detalhes nas próximas seções.
2.2.6 Suposições de Mundo Aberto e de Mundo Fechado
A suposição de mundo aberto (Open World Assumption — OWA) define que os dados
que não estão presentes na base de conhecimento de um host — e que não podem ser deduzi-
dos como consequência lógica dos dados presentes — não são considerados falsos, mas des-
conhecidos. Essa suposição é bastante útil em cenários onde a base de conhecimento é consi-
derada incompleta, i.e., é assumido que nem todos os fatos e axiomas que compõem o domí-
nio de aplicação são conhecidos. No entanto, as deduções lógicas feitas sobre o domínio co-
15
nhecido não devem possibilitar conclusões divergentes ao se adicionar à base novos fatos e
axiomas. Essa característica da suposição de mundo aberto é chamada de monotonicidade, e
pode ser expressa matematicamente como:
(a) Γ ⊢ C
(b) Γ, Α ⊢ C
Onde (a) representa um conjunto de fatos e axiomas conhecidos Γ que deduzem C (o

conjunto de conclusões possíveis). Pela suposição do mundo aberto a adição de um novo fato
Α ao conjunto das premissas não muda o conjunto C, como mostrado em (b). Assim, pela
semântica estabelecida para o mundo aberto, a adição de novas premissas nunca torna falsa
uma conclusão deduzida previamente e, portanto, sempre que não houver premissas suficien-
tes para se chegar a alguma conclusão, o resultado da dedução é considerado desconhecido,
em vez de errado ou falso.
Por outro lado, a suposição de mundo fechado (Closed World Assumption — CWA)
define que os fatos e axiomas que não são correntemente conhecidos, e que também não po-
dem ser deduzidos a partir dos fatos conhecidos, são sempre assumidos como falsos. A se-
mântica do CWA está relacionada ao conceito Negation as Failure (CLARK, 1978), onde
Clark afirma que a falsidade de uma informação P pode ser inferida se toda prova possível
para P falhar. Reiter (REITER, 1978) declara que em domínios de mundo fechado é natural
representar explicitamente somente os fatos positivos e assumir a verdade dos fatos negativos
por padrão.
Na CWA assume-se que a base de dados de um host possui informações completas a

cerca do domínio de aplicação. Este é o caso das bases de dados que seguem o modelo relaci-
onal, e.g., um banco de dados corporativo contendo os registros de todos os seus empregados.
Para ilustrar as características semânticas das duas suposições de mundo, supõe-se que
a Tabela 1 apresente um conjunto de voos conhecidos e disponíveis em território nacional.
Pela semântica adotada na suposição de mundo fechado, o domínio é assumido como comple-
to (i.e., não há lacunas de conhecimento sobre esse domínio), portanto, todos os voos domés-
ticos estão explicitamente representados na tabela e a ausência de um trecho específico impli-
ca que ele não existe. Assim, a falha ao localizar, por exemplo, o voo Gol 3700 que parte de
Fortaleza com destino à Recife permite que se conclua que esse voo não existe. O mundo é
16
fechado em torno dos fatos conhecidos na tabela e a negação de um fato pode ser inferida
implicitamente se sua contraparte positiva não estiver explicita.
Tabela 1: Origens e destinos de voos.
Voo Origem Destino

Gol 3700 Fortaleza Brasília
Gol 3700 Brasília São Paulo
TAM JJ025 Fortaleza Rio de Janeiro
TAM JJ020 São Paulo Curitiba
Por outro lado, a suposição de mundo aberto assume a possibilidade de haver informa-
ções sobre voos além dos listados na Tabela 1 e, portanto, exige que tanto os fatos positivos
quanto negativos estejam explicitamente disponíveis. A OWA não utiliza a convenção Nega-
tion as Failure e, assim, permite que haja lacunas de conhecimento no domínio da aplicação.
A OWA, dessa maneira, aplica-se a sistemas que possuem informações incompletas sobre um
domínio. Por causa disso, não é possível responder se o voo Gol 3700 de Fortaleza à Recife
existe ou não, esse resposta é indefinida, não computável, na OWA.
A principal diferença entre as OWA e CWA pode ser sumarizada na Figura 1, onde β
é um conhecimento (ou fato) que não está contido em uma base de dados e β também não
pode ser deduzido, por meio de lógica descritiva, a partir dos conhecimentos contidos nessa
mesma base.
Figura 1: Diferença semântica entre a suposição de mundo aberto e de mundo fechado.

17
As figuras 1.a e 1.b possuem as mesmas premissas, contudo suas conclusões são bas-
tante diferentes em razão da suposição de mundo adotada em cada caso. Enquanto a Figura
1.a conclui que β é desconhecido, a Figura 1.b assume o seu valor é falso.
2.2.7 Suposição de Nome Único
A suposição de nome único (Unique Name Assumption — UNA) é um conceito rela-

cionado às suposições de mundo aberto (OWA) e mundo fechado (CWA). Em lógicas que
adotam a UNA, nomes diferentes sempre se referem a entidades diferentes no mundo
(RUSSELL; NORVIG, 2003). Em geral, as aplicações aderentes a CWA adotam a suposição
de nome único, enquanto que as baseadas em OWA não adotam. A razão para a não adoção
da UNA na OWA está relacionada à incompletude dos dados no mundo aberto. Sempre há a
possibilidade de descoberta de novas relações entre fatos. Todavia, é possível adicionar UNA
manualmente à OWA. Por exemplo, a linguagem OWL não adota a UNA, mas fornece termos
em seu vocabulário para expressar se dois nomes denotam as mesmas ou diferentes entidades
(BECHHOFER et al., 2004).
1. owl:sameAs é o termo da OWL que afirma que dois nomes (ou URIs) se referem à
mesma entidade;
2. owl:differentFrom é o termo da OWL que afirma que dois nomes (ou URIs) se re-
ferem a entidades diferentes.
Por exemplo, as declarações abaixo afirmam verdades sobre um domínio:
(a) Hermano é cidadão do Brasil
(b) Hermano é cidadão de Portugal
(c) Uma pessoa só pode ser cidadã de um único País
Em aplicações aderentes a CWA essas declarações gerariam uma inconsistência, pois

foi declarado que uma pessoa só pode ser cidadã de um único país (afirmação c), e aqui
Hermano está associado a dois países diferentes, nas afirmações a e b. Por outro lado, em
aplicações aderentes a OWA, ao invés de gerar uma inconsistência, seria inferido um novo
fato: Brasil e Portugal são dois nomes para o mesmo País (ou Brasil
owl:sameAs Portugal). A razão para isso é que se uma pessoa só pode ser cidadã de
18
um único país e Hermano é cidadão do Brasil e de Portugal, então Brasil e Portugal são o
mesmo país.
De maneira simplificada, a suposição de nome único declara que se dois recursos pos-
suem nomes distintos, então serão considerados recursos distintos. A suposição de nome úni-
co é predominante nos modelos relacionais, enquanto que as tecnologias da Web semântica
(e.g. RDF e OWL) não a utilizam.
2.2.8 Suposição de Mundo Fechado Localmente
O conceito de uma suposição do mundo fechado localmente (Local Closed World As-
sumption — LCWA) foi introduzido pela primeira vez por Etzioni et al (ETZIONI;
GOLDEN; WELD, 1997), no contexto de bases de conhecimento para os agentes de software.
A motivação para esse tipo de suposição de mundo era ter um formalismo mais adequado para
efetuar inferências lógicas em ambientes multiagentes, onde cada agente conhecia sua própria
base de conhecimento completamente, mas não conhecia as informações mantidas nas bases
dos outros agentes.
Doherty et al. (DOHERTY; LUKASZEWICZ; SZALAS, 2000) afirmam que em mui-

tas aplicações reais a suposição de informação completa não é possível, e o CWA não pode
ser utilizado. Por exemplo, um agente ao ser inserido em um ambiente aberto pode interagir
com outros agentes, mas ele não tem ciência de todas as informações que são inseridas ou
removidas do ambiente pelos outros agentes. Ele não pode assumir, portanto, que o mundo é
fechado (CWA). Se por um lado, em aplicações como essa, a suposição de mundo aberto
(OWA) é a escolha correta a ser feita, por outro, a OWA não é adequada para representação e
implementação de mecanismos de verificação de integridade. Frequentemente os agentes de
software possuem uma visão completa dos dados mantidos em suas bases de conhecimento.
Isso permite que eles possam assumir a suposição de mundo fechado localmente (LCWA)
para seus próprios dados.
A OWA é adequada para contextos abertos, como a Web, pois nesse ambiente não há
garantias de um agente obter informações completas ou consistentes sobre algo. Todavia, si-
tuações naturalmente surgem em que seria preferível utilizar a CWA. Ela é o preferível, por
exemplo, quando os dados da base local de um agente podem ser considerados completos no
que diz respeito ao domínio em questão. A semântica da CWA permite que se façam verifica-
19
ções sobre a integridade dos dados locais, mantendo, portanto, uma representação consistente
do mundo, mesmo durante operações que resultam em mudanças sobre os dados.
Krisnadhi et al. (KRISNADHI; SENGUPTA; HITZLER, 2011) afirmam que a suposi-

ção de mundo fechado localmente (LCWA) é uma combinação dos mundos aberto (OWA) e
fechado (CWA), de forma a estender as capacidades do mundo fechado (de completude e ve-
rificação de integridade) para as linguagens de representação do conhecimento do mundo
aberto.
2.3 Tipos de acesso a dados interligados
Segundo (AUER et al., 2010), existem três tipos de acesso a dados interligados, como
mostrado na Figura 2:
Figura 2: Tipos de acesso a dados interligados. Figura adaptada de (AUER et al., 2010).
O primeiro tipo é o acesso por consulta, onde um agente envia para um endpoint, de
um serviço de acesso a dados, uma consulta SPARQL (HARRIS; SEABORNE, 2013) e rece-
be o resultado dessa consulta. O segundo tipo é o acesso em nível de entidade, onde um agen-
te executa uma requisição HTTP GET em uma URI identificadora de um recurso e recebe
uma representação do recurso em RDF como resposta a requisição. Por último, o acesso por
Dump, onde o agente executa uma requisição HTTP GET na URI identificadora de um grafo
RDF e obtêm todo o grafo como resultado.
20
2.3.1 Serviços de acesso por consulta
SPARQL (SPARQL Protocol and RDF Query Language) é uma linguagem de consul-
ta para bases de dados em RDF. Essa é a linguagem de consulta oficial do W3C e pode ser
utilizada para expressar consultas em diversas fontes de dados, estando os dados armazenados
nativamente em RDF ou representados em RDF via algum middleware. Além de consultas,
SPARQL contém recursos para fazer conjunção, disjunção, agregação, subconsultas, negação,
entre outras funcionalidades (HARRIS; SEABORNE, 2013).
A especificação recomendada pelo W3C para a construção de serviços de acesso por

consulta é a SPARQL 1.1 Protocol (FEIGENBAUM et al., 2013). Essa especificação descreve
um meio de transmissão, via HTTP, de consultas e atualizações SPARQL para um serviço de
acesso a dados processar a consulta e retornar os resultados para o cliente que os solicitou.
Essa especificação foi projetada para ser compatível com outras especificações, a SPARQL
1.1 Query Language (HARRIS; SEABORNE, 2013) — que define a linguagem de consulta
propriamente dita — e com a SPARQL 1.1 Update (GEARON; PASSANT; POLLERES,
2013) — uma extensão à linguagem SPARQL que permite operações de atualização de dados.
A SPARQL 1.1 Protocol define dois tipos operações HTTP, o primeiro para operações de
consulta e o segundo para operações de atualização de dados. As três especificações se relaci-
onam como ilustrado na Figura 3.
Figura 3: Relação entre especificações SPARQL.
Como exemplos de serviços de acesso a dados por consulta que implementam as espe-
cificações da Figura 3, pode-se citar o Fuseki Server6, o AllegroGraph Server7 e o Virtuoso
6
http://jena.apache.org/documentation/serving_data/
7
http://franz.com/agraph/allegrograph/
21
Universal Server8. O forte investimento do W3C no desenvolvimento de um conjunto de es-

pecificações relacionadas ao SPARQL possibilita que fornecedores diferentes implementem
serviços por consulta com interface e linguagem de consulta padronizada, o que contribui para
a integração de dados.
2.3.2 Serviços de acesso por Dump
A especificação recomendada pelo W3C para a construção de serviços de acesso por

Dump é a SPARQL Graph Store HTTP Protocol (OGBUJI, 2013). Essa especificação descre-
ve o uso dos métodos HTTP com a finalidade de gerenciar um Graph Store, i.e., um repositó-
rio de grafos RDF. Esse tipo de serviço de acesso a dados é bastante utilizado, por exemplo,
em processos de extração, transformação e carga.
Como exemplos de serviços de acesso por Dump, pode-se citar o Fuseki Server e o
Virtuoso Universal Server. Esses dois serviços implementam a especificação SPARQL Graph
Store HTTP Protocol, além da SPARQL Protocol com já foi citado na Seção 2.3.1.
2.3.3 Serviços de acesso em nível de entidade
A característica que melhor distingue os serviços de acesso a dados em nível de enti-

dade dos de acesso por consulta é que enquanto os primeiros utilizam os métodos HTTP
(GET, POST, PUT e DELETE) para manipulação das entidades mantidas no host e conven-
ções de URL para identificar essas entidades, os serviços por consulta utilizam apenas um
endpoint, por onde recebem comandos em uma linguagem de consulta (e.g. SPARQL).
O estilo arquitetural REST (FIELDING, 2000) guarda consonância com a arquitetura

da Web, a qual explica por que é adequado trabalhar com os métodos HTTP para manipular
recursos nomeados por URLs. Os Serviços Web RESTful utilizam esses métodos conforme a
semântica definida na especificação do próprio protocolo HTTP (FIELDING et al., 1999).
Esse tipo de serviço, frequentemente, adota o XML ou o JSON para representação de dados,
embora, tais serviços possam ser definidos independentemente do formato utilizado para
transmissão dos dados.
8
http://virtuoso.openlinksw.com/
22
Em razão da popularização da arquitetura REST, muitas empresas passaram a disponi-

bilizar seus dados por meio de serviços RESTful, também chamados de Web APIs ou REST
APIs. Contudo, diferentemente dos dois tipos de acesso vistos anteriormente, os serviços de
acesso em nível de entidade não possuem ainda uma especificação de fato. Maleshkova et al
(MALESHKOVA; PEDRINACI; DOMINGUE, 2010) afirmam que atualmente o desenvol-
vimento de Web APIs é bastante autônomo, orientado por normas ou regras não estabelecidas,
e a documentação dessas Web APIs comumente não é baseada em uma linguagem de descri-
ção de interface como WSDL, mas dada diretamente em HTML como parte de uma página
Web. Assim, pela falta de uma especificação adequada, cada fornecedor de dados acaba dis-
ponibilizando serviços com Web APIs proprietárias; e isso frequentemente torna tais serviços
incompatíveis um com outros.
A Microsoft e a SAP se uniram para desenvolver uma especificação de propósito geral

para serviços de acesso a dados em nível de entidade chamada Open Data Protocol (OData)
(PIZZO; HANDL; ZURMUEHL, 2014a). Essa especificação fornece uma maneira uniforme
para consultar e manipular conjuntos de dados por meio de operações de CRUD. Além disso,
esses dados são representados pelo modelo Entity Data Model (EDM), esse modelo baseia-se
no de Entidade-Relacionamento (CHEN, 1976) e estende seus usos tradicionais para o contex-
to da Web. No entanto, o OData foi projetado para representar dados apenas nos formatos
Atom (ZURMUEHL; PIZZO; HANDL, 2013) e JSON (HANDL; PIZZO; BIAMONTE,
2014). Não há, portanto, suporte a formatos aderentes ao modelo RDF, dificultando assim sua
utilização no contexto da Web de dados interligados.
Recentemente a especificação OData foi aprovada como um padrão na Organization

for the Advancement of Structured Information Standards (OASIS9). A OASIS é um consór-
cio global sem fins lucrativos que conduz o desenvolvimento, convergência e adoção de pa-
drões abertos para e-business, computação em nuvens, SOA, serviços Web, entre outros. Den-
tre os membros do consórcio estão grandes nomes da indústria de tecnologia da informação
como Microsoft, IBM, HP e Oracle.
Contudo, apesar dos esforços da OASIS, a especificação OData ainda é pouco adotada
pelos serviços de acesso a dados. Assim, o cenário atual da Web é composto por uma infini-
dade de serviços de dados com propósitos específicos, dentre os quais se destacam o Simple
9
http://www.oasis-open.org
23
Storage Service (S3)10, uma API REST da Amazon, o Twitter REST API11 e o Graph API12
do Facebook. Nesse cenário a integração de dados é uma tarefa bastante árdua, em razão da
heterogeneidade dos serviços, e mesmo que a especificação OData se tornasse um padrão
entre os provedores de dados, ainda haveria o problema da falta de alinhamento com os prin-
cípios dos dados interligados.
Motivados pelo cenário exposto acima, (SPEISER; HARTH, 2010) propuseram os

Linked Data Services (LIDS), uma especificação que permite expor diferentes APIs e fontes
de dados como dados interligados. A especificação LIDS apresenta convenções para interfa-
ces de acesso a serviços que são aderentes aos princípios dos dados interligados. LIDS propõe
a criação de envoltórios (Wrappers) sobre serviços Web pré-existentes (e.g. Twitter, Facebo-
ok, etc). Em razão disto, o acesso aos dados é indireto e não oferece suporte a escrita de da-
dos.
Lanthaler (LANTHALER; GUTL, 2011b) argumenta que em vez de fornecer dados

interligados por meio de serviços Web RESTful, os esforços atuais implantam endpoints
SPARQL, ou simplesmente fazem upload de dados estáticos (Dump), a fim de proporcionar o
acesso aos dados. Ele afirma que isso raramente reflete a natureza dos dados fornecidos, i.e.,
descrições sobre recursos interligados. Por fim, Lanthaler cita outro problema das abordagens
atuais com relação à Web de dados interligados; tais abordagens geralmente fornecem interfa-
ces apenas de leitura para os dados subjacentes.
Portanto, de maneira geral, ainda há uma expressiva carência de serviços de acesso a

dados em nível de entidade provedores de dados interligados, e os que existem possuem limi-
tações como, por exemplo, a falta de suporte à escrita.
2.4 Suporte à escrita para dados interligados
Tim Berners-Lee (BERNERS-LEE et al., 2009) afirma que a Web de dados interliga-
dos atual é majoritariamente uma Web apenas de leitura, e que embora essa Web permita a
integração, navegação e consultas estruturadas em grandes conjuntos de dados, ainda falta um
conceito geral para uma Web de dados de leitura e escrita.
10
http://docs.aws.amazon.com/AmazonS3/latest/API/APIRest.html
11
https://dev.twitter.com/docs/api
12
https://developers.facebook.com/docs/graph-api/using-graph-api/
24
Garrote (GARROTE; GARCÍA, 2011) afirma que a falta de um suporte à escrita para
os repositórios de dados interligados impõe barreiras à adoção dessa tecnologia.
Coppens (COPPENS et al., 2012) declara que as abordagens atuais para a publicação
de dados interligados na Web geralmente oferecem interfaces de consulta para os dados subja-
centes. Ele também argumenta que a Web começou como uma versão somente de leitura (i.e.,
Web 1.0), evoluiu para uma Web de leitura e escrita, onde os seres humanos podem colaborar
(i.e., Web 2.0), e é atualmente uma Web que adota tecnologias semânticas para que as máqui-
nas possam ler e entender os dados subjacentes (i.e., Web 3.0). Assim, Coppens conclui que
dada essa linha de evolução, o próximo passo lógico para uma Web 4.0 parece ser uma Web
semântica de leitura e escrita, onde as máquinas podem colaborar.
Em razão da necessidade de um mecanismo que permitisse a leitura e a escrita de da-

dos interligados, a IBM e outros (HOLBROOK et al., 2012) submeteram em 2012, ao W3C,
uma especificação que descreve um conjunto de boas práticas para a leitura e escrita de dados
interligados via HTTP. A especificação chamada Linked Data Basic Profile 1.0 (NALLY et
al., 2012) esclarece os conceitos definidos pelos quatro princípios de Tim Berners-Lee
(BERNERS-LEE, 2006) e os estendem, de maneira que os dados interligados possam ser uti-
lizados com o estilo arquitetural REST para integração de aplicações e manipulação de dados.
O modelo distribuído dos dados interligados torna-os adequados para integração de

dados armazenados em várias bases, sistemas de arquivos e aplicações. Algumas das caracte-
rísticas exploradas pelo Linked Data Basic Profile e que fazem os dados interligados em
combinação com o estilo arquitetural REST adequados para integração incluem:
1. Um conjunto uniforme de métodos para manipulação (leitura e escrita) de dados,

definido pelos métodos HTTP, que é universalmente compreendido e é constante
em todas as aplicações. Isso contrasta com o Remote Procedure Call (RPC), arqui-
tetura onde cada aplicativo tem um conjunto de métodos único que tem de ser
aprendido e codificado;
2. Um esquema de endereçamento universal fornecido pela URL, tanto para identifi-
car como para acessar os dados. Isso contraste com a arquitetura RPC onde não há
nenhuma maneira uniforme para identificar ou de acessar os dados;
3. Um modelo simples e extensível de dados, fornecido pelo RDF, para descrever os
dados sobre um recurso de uma forma que não necessita de conhecimento prévio
do vocabulário sendo usado.
25
Usando como ponto de partida o Linked Data Basic Profile 1.0, o W3C iniciou em
2012 um grupo de trabalho com o intuito de produzir uma recomendação, chamada Linked
Data Platform (SPEICHER; ARWE; MALHOTRA, 2014), que permita a leitura e a escrita
de dados interligados via HTTP, que tenha plena integração entre as tecnologias da Web se-
mântica — tais como o RDF e OWL — e que siga plenamente os princípios do estilo arquite-
tural REST. Portanto, o Linked Data Platform descreve um conjunto de melhores práticas
para a construção de serviços RESTful de dados com uma arquitetura de leitura e escrita de
dados interligados acessados via HTTP. Além disso, os dados mantidos pelos serviços são
representados por meio do modelo RDF.
Até a data de conclusão desta dissertação a especificação Linked Data Plataform ainda
não havia se tornado uma recomendação do W3C, embora já estivesse em uma etapa bem
avançada desse processo.
2.5 Verificação da integridade semântica
Os serviços de acesso a dados interligados com suporte à escrita são essenciais para a
evolução da Web. Contudo, esse suporte trás alguns desafios. Por exemplo, em cenários onde
um serviço aceita requisições para inserção, atualização e deleção de dados e onde tais requi-
sições são executadas por clientes diferentes e independentes entre si, existe uma preocupação
em se manter a consistência dos dados na base ao longo dessas requisições. A manutenção da
consistência desses dados é essencial nos casos onde o host assume que sua base de conheci-
mento é completa em relação a um determinado domínio.
Fang (FANG, 2013) argumenta que o problema de manter a integridade dos dados in-
terligados surge porque eles são baseados nas tecnologias da Web semântica (e.g., RDF e
OWL) e tais tecnologias empregam a suposição de mundo aberto (Open World Assumption —
OWA) e não adotam a suposição de nomes únicos (Unique Name Assumption — UNA). Es-
sas suposições são tipicamente adequadas para representar o conhecimento distribuído na
Web, onde dados completos sobre um determinado domínio não podem ser presumidos. Por
outro lado, isso torna difícil a utilização da OWL para fazer a verificação da integridade dos
dados no contexto do mundo fechado, onde o conhecimento sobre um domínio é sempre as-
sumido como completo.
26
Para ilustrar a limitação da OWL em verificar restrições de integridade no contexto do

mundo fechado, supõe-se um cenário onde uma base de conhecimento contém informações
sobre os produtos em estoque de uma empresa. Supõe-se também que o fabricante de cada
produto é sempre conhecido. Assim, é desejável um mecanismo de verificação de integridade
para o caso em que um produto seja adicionado à base sem a informação do fabricante. Em
OWL é possível expressar a exigência de que cada produto tenha um fabricante, contudo, em
razão da suposição de mundo aberto, a ausência dessa informação na base não iria causar uma
inconsistência lógica, mas apenas inferir que embora o produto possua um fabricante, esse é
desconhecido. Portanto, a semântica atual da OWL não pode ser utilizada para a verificação
de integridade no contexto do mundo fechado.
Todavia, em cenários de mundo fechado as restrições de integridade sobre as ontolo-

gias devem ser consideradas; pois, caso contrário, inconsistências ou dados incompletos pode-
riam ser inseridos na base. Hustadt (HUSTADT, 1994) provoca uma reflexão sobre a necessi-
dade de se utilizar a suposição de mundo fechado em linguagens de representação do conhe-
cimento — tipicamente projetadas para a suposição de mundo aberto. Ele argumenta que mui-
tas dessas linguagens são subconjuntos da lógica de primeira ordem e são, portanto, muitas
vezes indecidíveis ou semi-decidíveis. Em razão disso, algumas consultas feitas sobre bases
de conhecimento construídas com essas linguagens podem não retornar respostas. Por outro
lado, as mesmas consultas feitas sobre bases de conhecimento aderentes à suposição de mun-
do fechado sempre permitem a obtenção de uma resposta.
Em razão da necessidade de se adicionar uma semântica de mundo fechado à lingua-

gem OWL, Motik (MOTIK; HORROCKS; SATTLER, 2007) propõe uma extensão à OWL
que capta a intuição por trás dos mecanismos de restrição de integridade dos bancos de dados
relacionais. Motik declara que ao se satisfazer todas as restrições de integridade definidas em
uma ontologia, isso garante que todos os dados necessários foram especificados explicitamen-
te e, assim, permite detectar possíveis erros nesses dados. Contudo, uma premissa assumida
nessa abordagem é a de que uma ontologia é um modelo finito, i.e., totalmente conhecido,
assim como ocorre no modelo de dados relacional.
27
1 <owl:Class rdf:about="#Pessoa">
2 <rdfs:subClassOf>
3 <owl:Restriction>
4 <owl:onProperty rdf:resource="#temCPF"/>
5 <owl:onClass rdf:resource="#CPF"/>
6 <owl:qualifiedCardinality>1</owl:qualifiedCardinality>
7 </owl:Restriction>
8 </rdfs:subClassOf>
9 </owl:Class>
10
11 <owl:NamedIndividual rdf:about="#Pedro">
12 <rdf:type rdf:resource="#Pessoa"/>
13 </owl:NamedIndividual>
Listagem 1: Ontologia com uma restrição de cardinalidade definida.
A Listagem 1 apresenta um cenário que ilustra a razão pela qual a linguagem OWL
não é adequada para fazer a verificação de integridade dos dados. As linhas 1 a 9 apresentam
axiomas que descrevem que qualquer instância da classe “#Pessoa” deve ter exatamente um
CPF. Portanto, o fato descrito nas linhas 11 a 13, que declara que “#Pedro” é uma pessoa e
nada informa sobre seu CPF, deveria gerar uma violação de integridade. Contudo, a ontologia
da Listagem 1 não apresenta nenhuma violação, pois a restrição declarada nas linhas 3 a 7 não
são interpretadas como uma verificação de integridade, ao invés disso, essa restrição infere
que “#Pedro” possui um CPF desconhecido.
Em contraste, as restrições de integridade possuem um papel central nos bancos de da-

dos relacionais, onde elas garantem a integridade dos dados. Portanto, para permitir que res-
trições de integridade sejam declaradas em uma base de conhecimento, Motik propõe dividir
os fatos contidos na base em de três conjuntos:
 S: é um conjunto finito de axiomas TBox;

 C: é um conjunto finito de axiomas TBox interpretados como restrição e;
 A: é um conjunto finito de declarações ABox.
Assim, a ideia central da abordagem de Motik se resume em selecionar alguns axio-

mas do tipo TBox e lhes atribuir uma semântica distinta da semântica padrão da linguagem
OWL. A semântica dos axiomas pertencentes ao conjunto C não irá inferir novos fatos, mas
verificará se as declarações ABox existentes na base satisfazem o modelo descrito pelo con-
junto C.
Sirin, Tao e outros (SIRIN; TAO, 2009; TAO et al., 2010a, 2010b) declaram que para
usar a OWL tanto como linguagem de representação de conhecimento, quanto como meca-
nismo de restrição de integridade, é preciso combinar as semânticas do mundo aberto e do
28
mundo fechado. Para eles, em muitas aplicações centradas em dados interligados é desejável a
utilização de OWL para codificar as restrições de integridade que devem ser satisfeitas pelas
instâncias. No entanto, as condições que desencadeiam as violações de integridade em siste-
mas que usam a suposição de mundo fechado irão gerar novas inferências em aplicações onde
os dados são descritos pela linguagem OWL. Assim, eles propõem uma abordagem inspirada
no trabalho de Motik (MOTIK; HORROCKS; SATTLER, 2007), onde alguns axiomas TBox
são selecionados para representarem restrições de integridade e são, portanto, interpretados
com uma semântica diferente, própria para validação de dados. A principal diferença entre os
dois trabalhos reside no tratamento diferente que Sirin e Tao dão para os axiomas TBox inter-
pretados como restrições e que possuem disjunções.
2.6 Integração entre abordagens de suporte à escrita e ve-

rificação de integridade
No contexto dos serviços de acesso a dados interligados, várias pesquisas têm sido fei-
tas na direção de se criar uma especificação que permita o suporte adequado à escrita. Já no
contexto da Web de dados interligados, notoriamente na linguagem OWL, outras pesquisas
têm focado no desenvolvimento de um mecanismo de restrição de integridade aderente a su-
posição de mundo fechado. A integração entre essas duas linhas de pesquisa parece natural,
uma vez que se beneficiariam dessa integração, entre outras coisas, os serviços cujo domínio
de dados é considerado finito e os dados propriamente ditos são assumidos como completos.
Contudo, apesar dos benefícios identificados, tais abordagens são praticamente disjuntas.
Assim, dado a importância de se preservar a consistência dos dados na base de um

host, é razoável declarar que muitas organizações somente permitirão que seus serviços de
dados disponibilizem operações de escrita quando essa integração entre abordagens estiver
adequadamente resolvida. O trabalho proposto nesta dissertação, portanto, pretende preencher
essa lacuna de integração, como será visto nos próximos capítulos.
29
2.7 Sumário
Neste capítulo, foram mostradas a principais tecnologias relacionadas aos dados inter-
ligados. Também foram apresentados os conceitos sobre mundo aberto (OWA) e mundo fe-
chado (CWA) e suas derivações — conceitos nos quais toda linguagem de representação de
conhecimento se apoia. Além disso, este capítulo apresentou pesquisas recentes sobre o su-
porte à escrita de dados interligados e abordagens para sua verificação de integridade.
No próximo capítulo, será apresentada uma nova abordagem para especificação de

serviços de dados interligados com suporte à escrita. Essa abordagem pretende resolver algu-
mas limitações de propostas anteriores, tal como a falta de uma interface para descrever os
métodos e dados providos pelo serviço.
Capítulo 3
3
Serviços de Dados Semânticos
Este capítulo define o conceito de Serviços de Dados Semânticos, i.e., serviços Web
que implementam as operações de acesso, atualização, criação e exclusão de dados por meio
do protocolo HTTP, expõem os seus recursos como dados interligados e utilizam ontologias
para descrever sua interface de serviço.
3.1 Introdução
O termo Serviços de dados é usado neste trabalho para definir pontos de acesso a fon-
tes de dados por meio de serviços Web. Uma característica que distingue os serviços de dados
de outros tipos de serviços Web é que eles manipulam seus dados mediante as operações de
CRUD (Create, Read, Update e Delete), assim não há operações para computação de dados.
Tais serviços atuam como camadas de acesso a dados, o que permite abstrair a fonte de dados
do host. Assim, outros sistemas podem chamar as operações do serviço para solicitar ou exe-
cutar operações sobre esses dados. Os serviços de dados são, portanto, uma maneira útil de
fornecer dados para uma gama de consumidores por meio da Web.
Neste trabalho são propostos os Serviços de Dados Semânticos (SDS), pontos de aces-
so para dados que estão armazenados nativamente como RDF ou são visualizados como RDF
via algum middleware. Os SDS são descritos por interfaces SERIN (MUNIZ et al., 2011) e
estão alinhados ao estilo arquitetural REST (FIELDING, 2000). Portanto, o suporte à leitura e
à escrita em tais serviços é provido pelo protocolo HTTP (FIELDING et al., 1999).
Garrote (GARROTE; GARCÍA, 2011) afirma que os dados interligados estão rapida-
mente se tornando um importante mecanismo para expor dados estruturados na Web. Ele ar-
gumenta que a capacidade que diferentes fontes de dados interligados possuem de serem des-
critas por um vocabulário comum e utilizarem o mesmo modelo de dados abre novas possibi-
lidades na forma como esses dados podem ser utilizados. Contudo, ele conclui que a falta de
31
um suporte à escrita para os repositórios de dados interligados impõe barreiras à adoção dessa
tecnologia.
O propósito deste capítulo, portanto, é o de apresentar uma abordagem para construção

de serviços de dados que permitam a leitura e a escrita de dados interligados. Essa abordagem
expõe os dados de um host de acordo com o modelo RDF e permite que clientes possam ler e
modificar esses dados usando as operações HTTP (GET, POST, PUT e DELETE). Está fora
do escopo desse trabalho especificar adições ou modificações ao HTTP, tais como novos hea-
ders ou novos verbos. O uso do modelo RDF facilita a integração de dados entre sistemas e
aplicações. Além de disso, essa abordagem complementa o SPARQL e permite que os desen-
volvedores acessem os dados dos hosts de forma mais programática.
3.2 Usando URIs para Acessar Dados Interligados
A especificação de arquitetura da Web (JACOBS; WALSH, 2004) define o termo De-

referencing — traduzido, neste trabalho, como “desreferenciação” — como o ato de recuperar
um recurso a partir da URI que o referencia. Assim, uma URI é desreferenciável se ela repre-
senta o endereço de um recurso na Web e uma representação desse recurso pode ser recupera-
da ou modificada por meio dos operações HTTP (GET, POST, PUT, DELETE, etc).
Porém, nem toda URI é desreferenciável. Os elementos de uma tripla RDF, por exem-
plo, utilizam URIs unicamente para identificação, pois a especificação atual do RDF
(MANOLA; MILLER, 2004) não trata a desreferenciação dessas URIs. Por outro lado, os
serviços Web RESTful se comunicam com seus clientes por meio dos métodos HTTP para
obter e alterar dados em um host. Nesses serviços, os dados são identificados mediante URIs
que são desreferenciadas a cada operação. Portanto, a combinação do modelo RDF com os
serviços Web RESTful é natural, com RDF fornecendo uma representação padrão para codifi-
car os dados e identificação de seus elementos mediante URIs e os serviços RESTful forne-
cendo uma maneira de obter e alterar os dados. Vários autores, tanto na academia, quanto na
indústria, têm explorado formas de alinhar essas duas tecnologias de maneira adequada. Page
(PAGE; DE ROURE; MARTINEZ, 2011), por exemplo, apresenta um estudo onde são mos-
tradas as principais diferenças e similaridades entre o modelo RDF e o estilo arquitetural
REST, enquanto Kjernsmo (KJERNSMO, 2012) propõe que o suporte a hipermídia no RDF é
necessário para um melhor alinhamento ao estilo arquitetural REST.
32
Dentro do World Wide Web Consortium (W3C), o Grupo de Trabalho responsável pe-
la especificação SPARQL (HARRIS; SEABORNE, 2013) desenvolveu uma especificação
voltada para acessar dados em Graph Stores RDF por meio de serviços RESTful (OGBUJI,
2013). Contudo, mesmo nessa especificação ainda há a possibilidade dos dados RDF possuí-
rem URIs não desreferenciáveis, o que não é desejado. Em maio de 2012, o W3C em parceria
com a IBM e Oracle, criou um Grupo de Trabalho com a finalidade de desenvolver um corpo
de conhecimentos que sintetizem as melhores práticas para o desenvolvimento de serviços
RESTful alinhados ao modelo RDF. Esse grupo de trabalho está — pelo menos até a data de
conclusão deste trabalho — trabalhando na especificação Linked Data Platform 1.0
(SPEICHER; ARWE; MALHOTRA, 2014), cujo objetivo é se tornar uma recomendação do
W3C para o desenvolvimento de serviços Web RESTful capazes de ler e escrever dados inter-
ligados e adequados para o uso em integração de aplicações e construção de sistemas de sof-
tware modulares e interoperáveis.
3.3 Interface Semântica RESTful
Os serviços SDS utilizam interfaces semânticas RESTful, ou Semantic RESTful Inter-

face — SERIN, (MUNIZ et al., 2011) e (MUNIZ et al., 2013). SERIN é uma abordagem que
utiliza ontologias em linguagem OWL como interfaces abstratas no contexto dos serviços
Web RESTful. O termo interface abstrata enfatiza a ideia de que a interface pode ser imple-
mentada por vários serviços de dados ao mesmo tempo sem se vincular a nenhum em particu-
lar.
A interface SERIN é parte essencial dos Serviços de Dados Semânticos. Todos os da-
dos providos por esses serviços precisam seguir o modelo de dados RDF definido na interfa-
ce. Assim, as classes e propriedades da interface caracterizam semanticamente os dados man-
tidos no host. Essa interface é um documento OWL DL válido, portanto, seque as mesmas
regras de validade impostas à linguagem OWL DL. Dentre essas regras, uma que possui im-
portante relevância no contexto dos serviços de dados semânticos é a que diz que referências
URI para classes, propriedades e indivíduos devem ser disjuntas, i.e., classes e propriedades
não podem ser usadas como instâncias e vice versa. Essa separação imposta pela OWL DL é
fundamental para se definir a fronteira do que é interface e o que são os dados.
33
3.3.1 Separação do Conhecimento
As interfaces SERIN são uma evolução da visão de ontologia ativa definida por Neto
(NETO, 2007). Essa visão classifica o conhecimento que pode ser representado por uma onto-
logia em dois grupos, o conhecimento compartilhado e o conhecimento particular. Nessa clas-
sificação, o conhecimento compartilhado diz respeito ao modelo de dados, enquanto que o
conhecimento particular está relacionado às instâncias desse modelo. Por exemplo, se um
determinado agente requisita a um serviço de dados semânticos de uma universidade quais os
cursos ofertados por ela, ambos têm que saber o que significa “curso”. O termo “curso” deve
pertencer ao conhecimento compartilhado do transmissor e do receptor da comunicação. Con-
tudo, o agente não deve saber quais os cursos ofertados até que o serviço os informe. Esse
conhecimento da lista de cursos ofertados pela universidade em questão é particular apenas
àquela universidade. Por esse motivo, as ontologias utilizadas para construção de interfaces
SERIN frequentemente só possuem as definições de classes e propriedades, enquanto as ins-
tâncias que pertencem ao domínio definido pela interface são armazenadas na base de dados
do host, pois são informações particulares ao host e não devem fazer parte da ontologia, a
Figura 4 ilustra essa visão.
Figura 4: Os recursos apresentados em cada host são instâncias de classes e podem ser acessados por meio
dos Serviços de Dados Semânticos que adotarem a interface SERIN especificada.
34
Essa visão não é a que muitas abordagens utilizam. Normalmente, modelam se as on-
tologias como um conjunto único, composto por classes, propriedades e instâncias, onde as
instâncias fazem parte da ontologia e todo o conjunto está eventualmente compartilhado na
internet. Portanto, não é feita a distinção que é feita neste trabalho, de existir um modelo e
existir hosts que seguem o modelo. Os hosts possuem bases distintas cada qual seguindo o
modelo da ontologia. Essa abordagem é diferente, por exemplo, da Wikipédia, onde se supõe
que exista uma ontologia composta por classes, propriedades e instâncias.
Uma interface, de maneira geral, é um contrato que define quais dados podem ser tro-
cados entre o agente e o serviço e como essa troca pode ser feita, i.e., que métodos são permi-
tidos sobre os dados. Portanto, o conhecimento compartilhado — representado por meio da
interface — é de natureza estática, enquanto o particular — representado pelas instâncias ar-
mazenadas no host — é de natureza dinâmica.
Essa separação entre o modelo e as instâncias permite que quem vá criar as instâncias
no host não seja necessariamente quem modelou a ontologia. Essa característica torna a espe-
cificação SERIN uma boa candidata para ser utilizada na construção das interfaces de serviços
de dados semânticos. Um host que implementa uma interface SERIN oferece acesso a dados
que são instâncias das classes e propriedades definidas na interface. Os serviços de dados se-
mânticos usam os conceitos previamente estabelecidos na interface e os ligam semanticamen-
te aos dados armazenados no host do serviço.
3.3.2 Instância RDF: Uma unidade de recuperação de informação
O modelo RDF — Resource Description Framework (MANOLA; MILLER, 2004) —

é um arcabouço de propósito geral recomendado pelo W3C para a representação e transmis-
são de informações na Web. Esse modelo possui uma variedade de sintaxes, incluindo o
RDF/XML (BECKETT, 2004), o JSON-LD (SPORNY et al., 2014) e o Turtle (BECKETT et
al., 2014).
O modelo RDF expressa quaisquer informações como uma coleção de triplas, cada
tripla consistindo de um sujeito, um predicado e um objeto. O conjunto de tais triplas é cha-
mado de grafo RDF (KLYNE; CARROLL, 2004). A Figura 5 ilustra um diagrama de repre-
sentação de uma tripla, onde dois nós são ligados por um arco direcionado.
35
Figura 5: Estrutura de uma tripla RDF.
Este trabalho tem como uma de suas contribuições, definir o conceito de instância
RDF. Os serviços de dados semânticos expõem os dados armazenados em seus hosts como
instâncias RDF. Tais instâncias são trocadas entre o SDS e seus clientes por meio de docu-
mentos RDF válidos, contendo uma ou mais instâncias.
O conceito de instância proposto promove uma visão análoga a de um objeto no para-

digma da orientação a objetos — vide a Figura 6.a. Assim, uma instância RDF é o conjunto
de triplas necessário para representar uma instância de uma classe pertencente a uma interface
SERIN. Todas as triplas de uma instância RDF compartilham o mesmo nó sujeito — como
pode ser visto na Figura 6.b. Assim, toda instância é identificável pela URI do sujeito das tri-
plas que a compõe. Além disso, anotações presentes nas classes e propriedades da interface
indicam restrições que devem ser atendidas para que o conjunto de triplas possa ser conside-
rado uma instância. Portanto nem todo conjunto de triplas com o mesmo sujeito constitui uma
instância RDF.
Figura 6: Uma instância utilizando diversas sintaxes, em (a) um objeto na UML, em (b) um grafo RDF,
em (c) uma representação RDF/XML e em (d) uma representação em Turtle.
36
A Figura 6 mostra a mesma instância representada por diversas sintaxes. Em (a) é

mostrado um objeto no paradigma da orientação a objetos, em notação UML. A instância (b)
é representada como um grafo RDF, enquanto (c) mostra a instância na sintaxe RDF/XML e
(d) na sintaxe Turtle. Apesar de Turtle ser menos verborrágica e consequentemente mais legí-
vel para humanos, ela ainda é uma proposta de recomendação do W3C, enquanto que
RDF/XML já tem o status de recomendação.
3.3.3 Integridade Semântica
As especificações RDF e OWL são bastante promissoras para a representação e inte-

gração de dados, porém como são tecnologias aderentes à suposição de mundo aberto, elas
possuem forte ênfase na inferência de novas informações e não na verificação de integridade
dos dados. Essa característica pode não ser adequada para muitos serviços de dados que preci-
sam assegurar a integridade dos dados inseridos no host. A integridade semântica assegura
que os dados inseridos em um host reflitam os valores permitidos com precisão, em termos de
estrutura e conteúdo.
Um mecanismo básico de integridade semântica presente na linguagem OWL, bem

como em uma variedade de linguagens de programação e esquemas de bancos de dados, é a
verificação do tipo de dados. Por exemplo, se a propriedade “idade” da classe “Pessoa” per-
mite apenas números, então um valor fora desse domínio ao ser inserido na propriedade deve-
rá lançar um erro de violação de integridade semântica. Assim, o tipo de dados define os pos-
síveis valores que podem ser associados a uma propriedade.
Além do tipo de dados, os serviços de dados semânticos sequem mais duas suposições
de integridade semântica:
1. A suposição de mundo fechado localmente (LCWA) e;

2. A suposição de que todo recurso (e.g., classe, propriedade ou instância) possui
nome único.
A partir dessas suposições, as seguintes restrições devem ser adotadas pela interface
SERIN para assegurar a integridade semântica dos dados do serviço:
Restrições sobre instâncias: Instâncias mantidas em um host devem pertencer a uma

classe definida explicitamente na interface SERIN (Provide Explicit Typing). Assim essas
37
instâncias devem ser associadas a, pelo menos, uma classe. Além disso, todas as instâncias
gerenciadas pelo host são consideradas distintas entre si (owl:AllDifferent).
Restrições sobre classes: Dentro de uma interface SERIN não são permitidas classes
anônimas, nem classes intersection (owl:intersectionOf) e nem classes union (owl:unionOf).
Além disso, todas as classes definidas na interface são consideradas distintas entre si
(owl:AllDisjointClasses).
Restrições sobre propriedades: Toda propriedade, ou predicado, deve possuir um

domínio (rdfs:domain) e um contradomínio (rdfs:range). O domínio deve ser uma classe ex-
plicitamente definida dentro da interface SERIN. O contradomínio deve ser ou uma classe
explicitamente definida dentro da interface SERIN ou um tipo de dados. Além disso, todas as
propriedades são consideradas distintas entre si (owl:AllDisjointProperties).
Restrição de Integridade: A restrição de integridade especifica as condições para que

os dados possam ser inseridos em um host. Cada instância inserida precisa ser válida perante
essas condições. No próximo capítulo deste trabalho, será apresentado em detalhes um meca-
nismo de verificação de integridade que estende a especificação da interface SERIN.
Segundo as restrições apresentadas nesta seção, e impostas aos serviços de dados se-
mânticos, instâncias de classes que não estão presentes na interface, não podem ser inseridas
na base de dados do host que implementa aquela interface. Nem tais instâncias podem possuir
propriedades que também não estejam definidas na interface. Essas restrições alinham a inter-
face SERIN ao conceito de suposição de mundo fechado, onde não existem outros objetos no
mundo além daqueles designados pela interface.
3.3.4 Anotações para manipulação dos dados
As operações de inserção, atualização e remoção de instâncias em um serviço de dados

semânticos são definidas por meio de um conjunto de anotações aplicadas sobre as classes
definidas na interface SERIN. São quatro os tipos de anotações previstos: GET, POST, PUT e
DELETE. Essas anotações indicam a existência de quatro operações possíveis sobre os dados.
As quatro operações são mapeadas nos quatro métodos HTTP de mesmo nome. Os serviços
de dados semânticos expõem dados por meio do protocolo HTTP. Portanto, a intenção de
associar as anotações apenas aos métodos HTTP é manter aderência ao padrão sugerido pelo
38
estilo arquitetural REST. A Listagem 2 apresenta a ontologia SERIN com a descrição comple-
ta das anotações de operações HTTP.
1 <?xml version="1.0"?>
2 <rdf:RDF xmlns="http://www.unifor.br/serin.owl#"
3 xmlns:owl="http://www.w3.org/2002/07/owl#"
4 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
5 <owl:Ontology rdf:ID="http://www.unifor.br/serin.owl"/>
6 <owl:AnnotationProperty rdf:ID="#get"/>
7 <owl:AnnotationProperty rdf:ID="#delete"/>
8 <owl:AnnotationProperty rdf:ID="#put"/>
9 <owl:AnnotationProperty rdf:ID="#post"/>
10 </rdf:RDF>
Listagem 2: Ontologia que define as anotações da especificação SERIN.
As operações não permitidas pelo serviço de dados semânticos irão retornar o código
HTTP 405 — Método não permitido (Method Not Allowed).
3.3.5 Convenção de Endereçamento
Todos os dados manipulados via um serviço de dados semânticos são endereçados

usando URIs cuja regra de formação é bem definida. As URIs, portanto, seguem uma conven-
ção, e podem representar três tipos de recursos: uma instância, um conjunto de instâncias ou o
valor de uma propriedade.
Há também duas URIs especiais cujo propósito é de auxiliar a descoberta automática

de serviços na Web, por meio de uma máquina de busca (CHAVES et al., 2012). A primeira
URI retorna o conjunto de interfaces SERIN implementadas por um determinado host, en-
quanto a segunda retorna uma interface em particular. A Tabela 2 apresenta a estrutura de
cada tipo de URI.
Tabela 2: Convenção de endereçamento SERIN.
Recurso endereçável Formato das URIs válidas

Conjunto de Interfaces http://example.com/serin
Interface SERIN http://example.com/serin/{ontologia}
Conjunto de Instâncias http://example.com/serin/{ontologia}/{classe}
Instância http://example.com/serin/{ontologia}/{classe}/{id}
Valor de Propriedade http://example.com/serin/{ontologia}/{classe}/{id}/{propriedade}
39
Essas URIs são formadas por até seis componentes:
 Host: Componente obrigatório. Endereço do site provedor de dados (e.g.

http://www.example.com);
 /serin/: Componente obrigatório. É a raiz do serviço, indica o Endpoint onde os
serviços de dados semânticos estão disponíveis;
 {ontologia}: Define o endereço da interface SERIN implementada pelo host;
 {classe}: Define o endereço do conjunto de instâncias pertencentes à classe seleci-
onada;
 {id}: Identificador de uma instância;
 {propriedade}: Define o endereço do valor de uma propriedade de uma instância.
3.4 Cenário de Uso
Para ilustrar o funcionamento dos serviços de dados semânticos, suponha o cenário de

uso onde duas universidades, A e B, exponham seus dados por meio desses serviços. A Lista-
gem 3 mostra a interface SERIN que essas universidades poderiam utilizar para descrever os
tipos de dados (i.e., classes e propriedades) que elas pretendem expor.
2 <rdf:RDF xmlns="http://www.universidade.org/interface.owl#"
3 xml:base="http://www.universidade.org/interface.owl"
4 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
5 xmlns:serin="http://www.activeontology.com.br/serin.owl#"
6 xmlns:owl="http://www.w3.org/2002/07/owl#"
7 xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
9
10 <owl:Ontology
rdf:about="http://www.universidade.org/interface.owl">
11 <owl:imports rdf:resource="http://www.unifor.br/serin.owl"/>
12 </owl:Ontology>
13
14 <owl:Class rdf:about="#Professor">
15 <serin:get/>
16 <serin:post/>
17 <serin:put/>
18 <serin:delete/>
19 </owl:Class>
20
21 <owl:Class rdf:about="#Universidade"/>
22
23 <owl:ObjectProperty rdf:about="#trabalhaEm">
24 <rdfs:domain rdf:resource="#Professor"/>
25 <rdfs:range rdf:resource="#Universidade"/>
26 </owl:ObjectProperty>
27
28 <owl:DatatypeProperty rdf:about="#nome">
30 <rdfs:domain rdf:resource="#Universidade"/>
31 <rdfs:range rdf:resource="&xsd;string"/>
32 </owl:DatatypeProperty>
40
27
32
33 <owl:DatatypeProperty rdf:about="#CPF">
35 <rdfs:range rdf:resource="&xsd;integer"/>
37 </rdf:RDF>
Listagem 3: Ontologia representando interface SERIN.
A interface descrita na Listagem 3 define as classes “#Professor” e “#Universidade”,

além das propriedades “#nome”, “#CPF” e “#trabalhaEm”, que se relacionam como ilustrado
na Figura 7.
Figura 7: Classes e propriedades de uma interface SERIN com suas anotações de operações HTTP.
A classe “#Professor” está anotada com as quatro operações Get, Post, Put e Delete.
Para possibilitar a utilização dessas anotações, a interface de serviço precisa importar a onto-
logia SERIN, como mostrado na linha 11 da Listagem 3. A semântica dessas anotações é a
mesma definida para os métodos HTTP (FIELDING et al., 1999). Portanto, é possível recupe-
rar, atualizar e remover instâncias de professor mantidas em hosts de serviços de dados se-
mânticos. A Figura 8 mostra o cenário onde as duas universidades implementam os serviços
SDS que sequem a interface SERIN da Figura 7.
41
Figura 8: Universidades A e B compartilhando a mesma interface SERIN.
Por compartilharem a mesma interface, ambos os hosts das universidades adotam o

mesmo modelo de classes e propriedades para organizar seus dados. Assim, um agente que
conheça a ontologia e esteja em busca de um determinado professor poderá procurá-lo em
ambas as universidades da mesma forma. Essa característica facilita a comunicação por torna-
la mais homogênea.
Método GET
De acordo com a convenção de endereçamento proposta na Seção 3.3.5, a Figura 9

apresenta uma requisição GET válida para o serviço de dados semânticos da universidade A.
Essa requisição solicita a listagem de professores mantida no host.
Figura 9: Requisição HTTP GET para obter a lista de professores da Universidade A.
Na requisição GET ilustrada na Figura 9, os elementos que compõem a URL são:
1. http://www.universidade_A.br: O endereço do host da universidade;

2. /serin/: O endpoint onde o serviço de dados semântico está disponível;
3. www.universidade.org/interface.owl: O endereço da interface SERIN;
4. Professor: O nome da classe para a qual se solicitou a lista de instâncias.
O retorno esperado para a requisição da Figura 9 é apresentado na Listagem 4.

42
6
7 <Professor rdf:about="www.universidade_A.br/serin/www.universidade.org/interface.owl/Professor/1">
8 <CPF rdf:datatype="&xsd;integer">11111111111</CPF>
9 <nome rdf:datatype="&xsd;string">Frank Manola</nome>
10 <trabalhaEm rdf:resource="www.universidade_A.br/serin/www.universidade.org/interface.owl/Universidade/A"/>
11 </Professor>
12
15 <nome rdf:datatype="&xsd;string">Eric Miller</nome>
17 </Professor>
18
21 <nome rdf:datatype="&xsd;string">Graham Klyne</nome>
23 </Professor>
24
27 <nome rdf:datatype="&xsd;string">Jeremy J. Carroll</nome>
29 </Professor>
30 </rdf:RDF>
Listagem 4: Lista de professores retornada pela requisição HTTP GET.
A lista de professores retornada possui quatro instâncias da classe professor. É impor-

tante frisar que essa lista é particular à universidade A, e uma requisição HTTP GET similar
para a universidade B provavelmente irá retornar uma lista com instâncias diferentes. Outro
ponto importante a se observar é que todas as URIs que identificam instâncias são desreferen-
ciáveis. Assim, por exemplo, a URI da instância 1 (linha 7 da Listagem 4) pode ser utilizada
para se obter aquela instância em particular, como apresentado na Listagem 5.
GET /serin/www.universidade.org/interface.owl/Professor/1 HTTP/1.1

Host: www.universidade_A.br
Listagem 5: Requisição HTTP GET retorna um documento RDF como a instância "1" de professor.
Método DELETE
O método DELETE é sintaticamente análogo ao GET. Para remover da base de dados

do host da universidade A, a instância 1 inteira, i.e., a instância e todas as suas propriedades.
O comando DELETE utilizado deve ser o da Listagem 6.
DELETE /serin/www.universidade.org/interface.owl/Professor/1 HTTP/1.1

Host: www.universidade_A.br
Listagem 6: Requisição HTTP DELETE para remoção da instância 1.
A requisição DELETE solicita ao serviço de dados semânticos que remova a instância

1 e suas propriedades, i.e., remove todas as triplas com o mesmo sujeito. Esse comportamento
está alinhado com a visão dos SDS de que a unidade de informação é a instância. Esse não é o
comportamento padrão para a manipulação de dados em RDF, pois a granularidade do RDF é
43
muito baixa, i.e., as unidades de informação são as triplas (BIZER; HEATH; BERNERS-
LEE, 2009). Se a visão de triplas fosse adotada em detrimento da visão de instâncias, a requi-
sição DELETE iria remover apenas a tripla que define que a instância 1 é do tipo professor
(<1> <rdf:type> <#Professor>) e deixaria na base de dados todas as triplas de pro-
priedade “órfãs”. Isso não é o desejado, pois permitiria o armazenado de dados incompletos
nos serviços, possibilitando situações de inconsistência de dados no contexto da suposição de
mundo fechado localmente.
Método POST
A requisição POST solicita ao serviço de dados semânticos que uma nova instância se-
ja inserida na base de dados do host. Contudo, diferentemente das requisições GET e DELE-
TE, uma requisição POST deve possuir um corpo (ou payload), que deve ser passado junta-
mente com a mensagem de requisição HTTP. A Figura 10 ilustra esse comportamento, onde
uma agente solicita a inserção de uma nova instância no host da universidade A. O código
HTTP 201 Created indica que o SDS aceitou a requisição com sucesso.
Figura 10: Requisição HTTP POST e o retorno (código 201), indicando sucesso na criação da nova
instância.
Por exemplo, a Listagem 7 mostra a requisição POST para a inserção de uma quinta
instância de professor na universidade A.
1 POST /serin/www.universidade.org/interface.owl/Professor HTTP/1.1

2 Host: www.universidade_A.br
3
9 <rdf:Description>
10 <rdf:type rdf:resource="#Professor"/>
12 <nome rdf:datatype="&xsd;string">Pedro Porfírio Muniz</nome>
44
13 <trabalhaEm rdf:resource="www.universidade_A.br/serin
/www.universidade.org/interface.owl/Universidade/A"/>
14 </rdf:Description>
15 </rdf:RDF>
Listagem 7: Requisição POST com o corpo da requisição.
É importante notar que a requisição POST é efetuada sobre a URL:

http://www.universidade_A.br/serin/www.universidade.org/interface.owl/Professor
e que o payload (linhas 4 a 15) da requisição POST contém uma nova instância de professor
demilitada pela tag <rdf:Description> (linhas 9 a 14). Essa tag não contem a URI identifi-
cadora da instância (rdf:ID ou rdf:about), pois é função do serviço de dados semânticos
gerar uma nova URI válida para qualquer instância adicionada à base da universidade A. No
exemplo apresentado acima, a URI gerada poderia ser
www.universidade_A.br/serin/www.universidade.org/interface.owl/Professor/5.
Além da geração, o SDS retorna a URI para o cliente da requisição no corpo da mensagem de
resposta HTTP 201.
Método PUT
Por último, o quarto método HTTP adotado pelos serviços de dados semânticos é o
PUT. A requisição PUT solicita ao SDS que uma instância seja atualizada na base de dados
do host. Assim como no caso do POST, a requisição PUT também possui como payload um
documento RDF. Contudo, diferentemente da URL utilizada no POST, a URL da requisição
PUT deve identificar a instância que se deseja atualizar.
Da forma como foi definida na especificação do protocolo HTTP (FIELDING et al.,

1999), a semântica do método PUT substitui completamente o recurso endereçado na URL —
que está contido no servidor — por aquele contido no payload da requisição. Contudo, fre-
quentemente os serviços de dados semânticos estão interessados em atualizar apenas uma
propriedade de uma instância, e não substitui-la completamente. Para atender a essa necessi-
dade, por meio da convenção de endereçamento da especificação SERIN, é possível montar
uma URL que identifique uma propriedade de uma instância em particular.
Para exemplificar um cenário de uso da requisição PUT, suponha que se deseje atuali-
zar a propriedade “#CPF” da instância 5 (inserida pelo POST da Listagem 7 no exemplo ante-
rior).
45
1 PUT /serin/www.universidade.org/interface.owl/Professor/5/CPF HTTP/1.1

3
9 <Professor rdf:about="www.universidade_A.br/serin
/www.universidade.org/interface.owl/Professor/5">
11 </Professor>
12 </rdf:RDF>
Listagem 8: Requisição HTTP PUT para atualização da propriedade "#CPF" da instância 5.
A Listagem 8 mostra a requisição PUT utilizada para atualizar o valor da propriedade

“#CPF” para 888.888.888-88. A URL válida para essa requisição é a URI identificadora da
instância 5 concatenada ao sufixo “/CPF”. Essa nova URL indica que se deseja atualizar ape-
nas essa propriedade na instância 5.
A atualização simultânea de duas ou mais propriedades de uma determinada instância

só é possível passando a instância com todas as suas propriedades no payload da requisição,
pois assim o PUT irá substitui-la completamente no host. A semântica do método PUT não
permite atualizar apenas um subconjunto específico de propriedades da instância, para esse
tipo de necessidade uma possível solução seria a adoção do método HTTP PATCH. Contudo,
neste trabalho esse método não é tratado, pois está fora do escopo dos serviços Web RESTful
tradicionais.
Por fim, a atualização de uma propriedade com cardinalidade maior que 1 requer al-
guns cuidados. Para exemplificar essa situação suponha que um professor trabalhe na univer-
sidade A, como definido na linha 4 da Listagem 9, e que começará a trabalhar também na uni-
versidade B.
1 <Professor rdf:about="…/interface.owl/Professor/5">
3 <nome rdf:datatype="&xsd;string">Pedro Porfírio</nome>
4 <trabalhaEm rdf:resource="…/interface.owl/Universidade/A"/>
5 </Professor>
Listagem 9: Instância de professor com uma propridade "#trabalhaEm".
A requisição PUT deve acrescentar a nova relação “#trabalhaEm” sem remover a que
já existe, como é mostrado na Listagem 10.
46
1 PUT /serin/www.universidade.org/interface.owl/Professor/5/trabalhaEm HTTP/1.1

3
9 <Professor rdf:about="…/interface.owl/Professor/5">
10 <trabalhaEm rdf:resource="…/interface.owl/Universidade/A"/>
11 <trabalhaEm rdf:resource="…/interface.owl/Universidade/B"/>
12 </Professor>
13 </rdf:RDF>
Listagem 10: Requisição PUT para adicionar duas propriedades "#trabalhaEm" à mesma instância de
professor.
Note que payload da requisição PUT precisa reenviar a relação da linha 10 para o ser-
viço de dados semânticos junto com a nova relação da linha 11, pois caso contrário, isso indi-
caria para o SDS que o professor iria trabalhar apenas na universidade B e não mais na A. Isso
acontece por que o método PUT sempre remove todas as triplas para reinseri-las novamente.
3.5 Sumário
Neste capítulo, foram apresentados os serviços de dados semânticos como uma abor-
dagem para construção de serviços de acesso a dados interligados. Foram mostrados os prin-
cipais desafios a serem superados para a construção de serviços Web RESTful alinhados ao
modelo de dados RDF. Também foi explicada como a abordagem SERIN, para construção de
interfaces semânticas, se relaciona com os serviços de dados semânticos.
No próximo capítulo, será apresentado um mecanismo de verificação de integridade de

dados para os serviços de dados semânticos. Esse mecanismo estende a especificação SERIN,
incorporando um novo conjunto de anotações que pretende descrever as condições permitidas
para um SDS aceitar a inserção, deleção, atualização ou recuperação de dados.
Capítulo 4
4
Restrições de Integridade na Interface

SERIN
Este capítulo define o mecanismo de restrição de integridade que dá suporte aos ser-
viços de dados semânticos.
4.1 Introdução
No capítulo anterior, foram apresentados os serviços de dados semânticos (SDS). Es-

ses serviços utilizam as interfaces SERIN (MUNIZ et al., 2013) para descrever os dados dis-
poníveis em um host. Além disso, mostrou-se que tais interfaces são ontologias construídas na
linguagem OWL. Contudo, a semântica da OWL endereça os cenários onde o conhecimento
completo a cerca dos dados de um domínio de aplicação não pode ser assumido (TAO et al.,
2010a). O que a torna apropriada para contextos onde os dados são incompletos. As duas
principais características da OWL são:
 A presença de uma semântica baseada na suposição de mundo aberto, i.e., uma declaração
que não está explicitamente disponível no domínio ou que não pode ser inferida a partir
dos fatos disponíveis não pode ser assumida como falsa, mas como desconhecida.
 A ausência da suposição de nome único, i.e., dois nomes diferentes podem referenciar um
mesmo indivíduo.
Contudo, em cenários onde os dados manipulados pelos serviços de dados semânticos

precisam ser completos, essas características podem dificultar a utilização da OWL para a
verificação de integridade de dados. É conveniente, assim, que esses serviços possuam meca-
nismos de verificação de integridade que permitam superar as limitações expostas.
O propósito deste capítulo, portanto, é o de estender o conjunto de anotações da espe-

cificação SERIN com anotações que permitam a verificação de restrições de integridade base-
48
ada na suposição de mundo fechado localmente e aplicada ao contexto dos serviços de dados
semânticos. Tais restrições de integridade são, assim, mecanismos que verificam se todas as
informações necessárias foram fornecidas explicitamente.
4.2 Restrições integridade via interface SERIN
Mecanismos de verificação de integridade de dados são fundamentais para o sucesso

de qualquer sistema centrado em dados. A integridade dos dados é essencial para muitas apli-
cações (e.g. bancárias, controle de tráfego aéreo e telecomunicações). A CWA possui um su-
porte adequado para checagem e validação de dados. Assim, se os dados requeridos não aten-
derem todas as restrições de integridade um erro é gerado. Em contraste, na OWA as restri-
ções não são utilizadas para a validação de dados, mas para inferência.
Apesar de a linguagem OWL possuir uma expressividade que a permite representar

eficientemente um modelo de dados, ela não pode facilmente ser usada como uma linguagem
de esquema. As linguagens de esquema são utilizadas para representar modelo de dados bem
como para representar as restrições de integridade dos dados. Essas linguagens são utilizadas,
tipicamente, em bancos de dados relacionais ou dados XML. Em razão da suposição de mun-
do aberto adotada pelo RDF e OWL, e a falta de suposição de nome único, os axiomas defini-
dos em uma ontologia OWL se propõem essencialmente a inferir novas informações e não a
fazer checagem de consistência dos dados. A semântica da OWL é capaz de detectar inconsis-
tências lógicas, mas somente quando dois fatos contraditórios estão explicitamente declarados
na ontologia. A ausência de informações não causa uma inconsistência em razão da suposição
de mundo aberto.
Motik e outros (MOTIK; HORROCKS; SATTLER, 2007) argumentam sobre as van-

tagens de se estender a semântica da OWL com características do mundo fechado, com o in-
tuito de permitir a utilização da OWL tanto para inferir novas informações como para validar
dados.
As interfaces SERIN, utilizadas para descrever os serviços de dados semânticos, em

sua especificação inicial (MUNIZ et al., 2011) carecem de um mecanismo de verificação de
integridade de dados compatível com a CWA. Na próxima seção, será apresentado um con-
junto de anotações desenvolvidas como um mecanismo de verificação de integridade de dados
que estende as interfaces SERIN, habilitando uma forma de LCWA para os dados manipula-
49
dos por serviços de dados semânticos. Essa abordagem, contudo, não implica em perda de
expressividade do modelo RDF que descreve os dados manipulados por esses serviços.
4.3 Anotações para restrição de integridade
As anotações previstas na especificação SERIN definem apenas as operações possíveis

sobre os dados. Este trabalho estende essa especificação, propondo mais seis anotações:
NotNull, Unique, Id, ForeignURI, Embedded e Internal. Essas novas anotações são importan-
te para adequar a interface SERIN à validação de integridade de dados nos moldes da LCWA.
As cinco primeiras anotações se aplicam as propriedades, enquanto a última às classes defini-
das na interface SERIN. A semântica da maioria dessas anotações é semelhante a das restri-
ções de integridade encontradas nos bancos de dados relacionais.
4.3.1 Anotação NotNull
A anotação NotNull obriga que uma instância possua um valor não nulo associado a
propriedade anotada. Essa anotação, portanto, assegura que uma instância declare explicita-
mente a propriedade que se deseja manter no host.
A anotação NotNull é inspirada na restrição de obrigatoriedade dos bancos de dados

relacionais. Silberschatz e outros (SILBERSCHATZ; KORTH; SUDARSHAN, 2005) afir-
mam que a especificação do NOT NULL proíbe a inserção de um valor nulo para um deter-
minado atributo. Qualquer modificação de banco de dados que causaria a inserção de um nulo
em um atributo declarado para ser NOT NULL gera uma violação de integridade.
Existem muitas situações onde se deseja evitar valores nulos. A Figura 11, por exem-
plo, apresenta duas instâncias da classe “#Aluno”. A instância “#Hermano” está explicitamen-
te associada ao nome do aluno por meio da propriedade “#nome”, enquanto que “#Pedro”
possui um nome desconhecido. Espera-se que todos os alunos registrados no host de uma uni-
versidade, entre outras informações, tenham seus nomes explicitamente cadastrados. É neces-
sário então que a ontologia utilizada para descrever a interface SERIN de um serviço de dados
semânticos defina que não são permitidas inserções de instâncias de aluno sem a propriedade
“#nome” explicitamente declarada.
50
Figura 11: Duas instâncias da classe “#Aluno”, uma com e a outra sem a propriedade “#nome”.
A Listagem 11 mostra a ontologia que descreve os dados do exemplo acima. A lin-

guagem OWL possui um vocabulário bastante rico, onde é possível definir a cardinalidade de
uma propriedade. As linhas 3 a 9 da Listagem 11 mostram uma restrição que declara que a
propriedade “#nome” deve ter exatamente um valor associado a ela. Esse recurso, a primeira
vista, parece ser suficiente para assegurar que nenhuma instância fique sem a propriedade
“#nome”, pois, caso contrário, isso poderia significar um aluno sem nome, o que claramente
violaria a cardinalidade definida. Contudo, a semântica a linguagem OWL é aderente à supo-
sição de mundo aberto, o que significa que um aluno sem nome é, na verdade, um aluno com
um nome, embora desconhecido. Nomes desconhecidos não violam a restrição de cardinali-
dade apresentada. Portanto, a restrição owl:qualifiedCardinality não é adequada como meca-
nismo de verificação de integridade para a LCWA.
1 <owl:Class rdf:about="#Aluno">
2 <rdfs:subClassOf>
3 <owl:Restriction>
4 <owl:onProperty rdf:resource="#nome"/>
5 <owl:qualifiedCardinality>
6 1
7 </owl:qualifiedCardinality>
8 <owl:onDataRange rdf:resource="&xsd;string"/>
11 </owl:Class>
12
14 <rdfs:domain rdf:resource="#Aluno"/>
Listagem 11: Restrição de cardinalidade para a ontologia Aluno.
A anotação NotNull se propõe a promover o comportamento adequado de restrição de

integridade para propriedades obrigatórias. A Listagem 12 apresenta a definição da proprie-
dade “#nome” como a anotação NotNull em destaque. Essa anotação informa ao serviço de
dados semânticos que a propriedade “#nome” é obrigatória, e assim, nenhuma instância de
aluno pode ser mantida no host sem uma associação explicita a essa propriedade.
51
2 <serin:notNull/>
Listagem 12: Propriedade “#nome” com anotação NotNull.
A partir das anotações declaradas na interface SERIN, os serviços de dados semânti-

cos que aderirem à interface devem verificar para todas as requisições POST, PUT ou DELE-
TE recebidas, se os dados enviados ou modificados pelas requisições HTTP não violam a res-
trição NotNull da interface. A Listagem 13 mostra uma requisição HTTP POST válida para a
anotação NotNull.
1 POST /serin/interface.owl/Aluno/Hermano HTTP/1.1

2 Host: www.unifor.br
3
4 <Aluno rdf:about="#Hermano">
5 <nome rdf:datatype="&xsd;string">Hermano Lira</nome>
6 </Aluno>
Listagem 13: Requisição HTTP POST para inserir uma instância de "#Aluno".
É importante destacar que a ausência da linha 5 na Listagem 13, i.e., se o nome do

aluno não for explicitamente declarado na requisição HTTP, o comando POST retornará o
código HTTP 412, Precondition Failed, e o serviço de dados semânticos não permitirá que a
nova instância seja armazenada no host.
A anotação NotNull permite que se mantenha no host dados tão completos quanto se
deseje. Portanto, essa anotação contribui para o suporte a LCWA nos serviços de dados se-
mânticos. Atualmente não é possível obter esse tipo de suporte apenas com o vocabulário de-
finido na linguagem OWL por ela adotar unicamente a suposição de mundo aberto.
4.3.2 Anotação Unique
A anotação Unique verifica se os valores associados à propriedade anotada são únicos.

Para tais propriedades, não é permitido haver repetição de valores dentro de um determinado
host. Essa anotação não obriga que os valores sejam definidos explicitamente para a proprie-
dade, apenas verifica para os que forem definidos, se são únicos ou não. Caso haja a necessi-
dade de obrigatoriedade, a propriedade deve ser anotadas com NotNull, além de Unique.
A anotação Unique é inspirada na restrição de unicidade dos bancos de dados relacio-

nais. Silberschatz e outros (SILBERSCHATZ; KORTH; SUDARSHAN, 2005), afirmam que
52
a especificação UNIQUE é definida como um conjunto de atributos de uma tabela, tal que
nenhum par de linhas essa tabela possui valores de atributos iguais. Entretanto, os valores dos
atributos podem ser nulos — a menos que tenham sido explicitamente declarados como sendo
NOT NULL — pois um valor nulo não se iguala a qualquer outro valor. É possível haver vá-
rias propriedades de uma classe com a anotação Unique. Contudo, a unicidade de cada propri-
edade é independente, ao contrário dos bancos de dados onde é possível combinar várias co-
lunas de maneira a obter a unicidade da combinação de valores das colunas.
Na linguagem OWL, se uma propriedade é declarada como inversamente funcional,

então o objeto associado a essa propriedade determina exclusivamente o sujeito, i.e., a instân-
cia. Mais formalmente, se P é uma owl:InverseFunctionalProperty, então isso assegura que
um valor y só pode ser o valor de P para uma única instância x, desse forma, não pode haver
duas instâncias distintas x1 e x2, tais que ambos os pares (x1, y) e (x2, y) são exemplos de P,
com é mostrado na Figura 12.
Figura 12: Apenas uma relação P(x, y) é permitida para propriedades InverseFunctionalProperty.
A propriedade owl:InverseFunctionalProperty, se aplica apenas a propriedades do tipo

owl:ObjectProperty. Na OWL Full as propriedades de tipo owl:DatatypeProperty são sub-
classes de owl:ObjectProperty, assim uma propriedade inversamente funcional pode ser defi-
nida para qualquer tipo de propriedade, sem restrição. Contudo, a interface SERIN é uma es-
pecificação alinhada à OWL DL, onde propriedades do tipo owl:ObjectProperty e
owl:DatatypeProperty são disjuntas. Portanto, nesse caso uma propriedade do tipo
owl:DatatypeProperty não pode ser definida como inversamente funcional.
Na Figura 13, é declarado que o aluno “#Hermano” possui a matrícula 10001, enquan-
to que o aluno “#Pedro” possui a matrícula 20001. Supondo que a matrícula é uma proprieda-
de que identifica unicamente um aluno, é necessário que o serviço de dados semânticos asse-
gure a consistência dos dados recusando a inserção de outro aluno que esteja associado a uma
matrícula em uso.
53
Figura 13: Exemplo de alunos e suas matrículas.
A propriedade “#matricula” não pode ser do tipo owl:InverseFunctionalProperty, pois

os valores inteiros pertencem ao tipo owl:DatatypeProperty. Mesmo que esse exemplo fosse
remodelado e os valores associados à propriedade “#matricula” fossem objetos ou invés de
inteiros, ainda assim, a semântica da owl:InverseFunctionalProperty na OWL ainda não seria
suficiente para assegurar a consistência dos dados. Isso por que em razão da ausência da su-
posição de nome único, ao inserir um novo aluno com matrícula 10001 ao conjunto da Figura
13, a OWL iria inferir que esse novo aluno é o mesmo aluno que “#Hermano”, e não iria re-
cusar a inserção, como é o desejado.
A anotação Unique visa resolver essas limitações da linguagem OWL, promovendo

um comportamento adequado de restrição de integridade para propriedades onde se deseja
manter valores únicos. Na Listagem 14 é apresentada a definição da propriedade “#matricula”
como a anotação Unique em destaque. Essa anotação informa ao serviço de dados semânticos
que o campo matrícula é único, e assim, dois alunos não podem ser armazenados no mesmo
host e associados à mesma matrícula.
1 <owl:DatatypeProperty rdf:about="#matricula">
2 <serin:unique/>
Listagem 14 Propriedade #matricula com anotação Unique.

trição Unique da interface. A Listagem 15 mostra uma requisição HTTP POST onde a anota-
ção Unique é verificada.
54
1 POST /serin/interface.owl/Aluno/Joao HTTP/1.1

3
4 <Aluno rdf:about="#Joao">
5 <matricula rdf:datatype="&xsd;integer">30001</nome>
6 </Aluno>
Listagem 15: Requisição POST válida, desde que não haja outro aluno no host com a mesma matrícula.
É importante destacar que caso o valor da matrícula definido na linha 5 da Listagem

15 já exista no host, a requisição POST retornará o código HTTP 412, Precondition Failed, e
o serviço de dados semântico não permitirá que a nova instância seja armazenada.
A anotação Unique permite que se identifique uma instância dentro de um host por
meio da propriedade anotada. Portanto, essa anotação contribui para o suporte a suposição de
nome único nos serviços de dados semânticos. A partir dessa anotação é possível inferir se
duas instâncias são distintas entre si. A linguagem OWL, em sua versão atual (HITZLER et
al., 2012), não permite essa suposição. A menos que uma declaração explícita seja feita de
que duas instâncias se referem à mesma ou a diferentes indivíduos por meio dos termos:
owl:sameAs, owl:differentFrom ou owl:AllDifferent.
4.3.3 Anotação Id
A anotação Id é inspirada no conceito de chave primária dos bancos de dados relacio-

nais. Silberschatz e outros (SILBERSCHATZ; KORTH; SUDARSHAN, 2005) afirmam que
o termo chave primária denota um ou mais atributos escolhidos pelo projetista de banco de
dados como principal meio de identificar tuplas dentro de uma relação. Uma chave primária é
uma propriedade da relação inteira, e não das tuplas individuais. Nenhum par de tuplas na
relação pode ter o mesmo valor nos atributos de chave ao mesmo tempo. Assim, é necessário
que os atributos de chave primária sejam não nulos e únicos.
A anotação Id, portanto, possui a semântica combinada das anotações NotNull e Uni-
que em uma única declaração. Proíbe várias instâncias de ter o mesmo valor na mesma pro-
priedade e proíbe os valores de serem nulos. Além disso, é possível anotar várias proprieda-
des, o que possibilita criar identificadores compostos, equivalente à chave primária composta
do modelo relacional.
No modelo relacional, os campos que permitem identificar unicamente uma linha (tu-
pla) em uma tabela são os candidatos naturais à chave primaria. Da mesma maneira, é interes-
55
sante que os serviços de dados semânticos possuam um mecanismo similar, para que instân-
cias sejam unicamente identificáveis. Na especificação original de SERIN (MUNIZ et al.,
2011), nenhuma anotação foi proposta com a finalidade de identificar uma instância. Enten-
deu-se na época que a URI do sujeito já fazia esse papel. Toda instância é um conjunto de
triplas RDF que compartilham o mesmo sujeito, além disso, a especificação RDF propõe que
sujeitos e predicados obrigatoriamente sejam identificados por uma URI válida. No escopo de
um único host a URI do sujeito pode ser utilizada como identificador único, pois o próprio
host é quem controla a criação e utilização dessas URIs. Porém, em cenários onde vários hosts
são considerados e em razão da ausência de suposição de nome único, duas URI distintas po-
dem apontar para a mesma instância como mostra a Figura 14.
Figura 14: Dois hosts distintos mantendo dados de uma mesma pessoa.
O exemplo apresentado na Figura 14 ilustra o cenário onde um professor universitário

de CPF “222.222.222-02” trabalha nas universidades A e B, distintas entre si. Supondo que o
servidor de dados semântico da universidade A esteja disponível na URL
www.univA.br/serin e de maneira similar a URL da universidade B esteja em
www.univB.br/serin, então as URIs que identificam as instâncias “#Pedro” e “#Porfi-
rio” são respectivamente:
1. www.univA.br/serin/interface.owl/Professor/Pedro e;
2. www.univB.br/serin/interface.owl/Professor/Porfirio.
Por serem mantidas em hosts diferentes que por sua vez são controlados por universi-
dades diferentes e independentes entre si, não há garantias de que as URIs 1 e 2 sejam iguais.
56
Na verdade, pela convenção de endereçamento definida pela especificação SERIN, URIs de

hosts diferentes sempre serão diferentes.
Contudo, as duas instâncias “#Pedro” e “#Porfirio” representam a mesma pessoa e a

formalização desse conhecimento é importante para, por exemplo, uma análise comparativa
entre os dados dos hosts ou para integração de dados. A linguagem OWL possui em seu vo-
cabulário o termo owl:sameAs, utilizado para definir que Pedro é a mesma instância que Por-
fírio (“#Pedro” owl:sameAs “#Porfirio”). Por OWL supor o mundo aberto, o fato de “#Pedro”
e “#Porfirio” representarem a mesma pessoa não pode ser inferido com base na igualdade dos
valores da propriedade “#CPF”, necessitando, assim, ser declarado explicitamente por meio
do termo owl:sameAs. No entanto, manter declarações explícitas de igualdade pode ser difícil,
especialmente quando instâncias estão sendo adicionadas e removidas do host dinamicamente.
A anotação Id se propõe a permitir que inferências desse tipo sejam feitas, e fatos co-
mo “#Pedro” owl:sameAs “#Porfirio” sejam inferidos ao invés de serem declarados explici-
tamente. Isso é possível por que ambos dos hosts, A e B, compartilham a mesma interface
SERIN, portanto, a propriedade “#CPF” é definida como um identificador único para o domí-
nio de dados definido na interface e não para um ou outro host.
A Listagem 16 apresenta a definição da propriedade “#CPF” com a anotação Id em

destaque. Essa anotação permite identificar que se duas instâncias em hosts diferentes possu-
em o mesmo valor para a propriedade anotada, então tais instâncias representam o mesmo
indivíduo.
1 <owl:DatatypeProperty rdf:about="#CPF">
2 <serin:id/>
Listagem 16: Propriedade #CPF com anotação Id.

trição Id da interface. A Listagem 17 mostra uma requisição HTTP POST para inserção do
professor Pedro, cujo CPF é 222.222.222-02, em um host. Como a propriedade “#CPF” está
anotada com serin:id, o serviço de dados semânticos requisitado somente efetuará a inserção
no host após verificar que não há outra instância de “#Professor” com o mesmo CPF no mes-
57
mo host. Da mesma forma, o serviço de dados semânticos também não efetuará a inserção
caso a instância esteja sem a propriedade CPF definida explicitamente. Nessas duas situações
será retornado o código HTTP 412, Precondition Failed, alertando para a falha na operação.
1 POST /serin/interface.owl/Professor/Pedro HTTP/1.1

3
4 <Professor rdf:about="#Pedro">
5 <CPF rdf:datatype="&xsd;integer">22222222202</nome>
6 </Professor>
Listagem 17: Requisição POST para inserir uma instância da classe "#Professor".
A anotação Id permite que se identifique uma instância dentro do conjunto de hosts

que compartilham a mesma interface SERIN, inclusive inferindo que instâncias em hosts dife-
rentes representam o mesmo indivíduo. Essa anotação reforça juntamente com a anotação
Unique o suporte a suposição de nome único nos serviços de dados semânticos.
4.3.4 Anotação ForeignURI
A anotação ForeignURI obriga que o valor da propriedade anotada seja uma URI de
uma instância mantida ou pelo próprio host ou definida dentro da sua interface SERIN. Por-
tanto, URIs de instâncias externas à base de dados do host, bem como de interfaces e ontolo-
gias alheias ao serviço de dados semânticos, não podem ser associadas a esse tipo de proprie-
dade. Essa anotação se aplica apenas às propriedades do tipo owl:ObjectProperty, pois as
propriedades owl:DatatypeProperty possuem um contradomínio (rdfs:range) que pode ser
definido apenas por tipos primitivos; os quais não possuem URIs.
Essa anotação é inspirada nas chaves estrangeiras (Foreign Key) dos bancos de dados
relacionais. Silberschatz e outros (SILBERSCHATZ; KORTH; SUDARSHAN, 2005) afir-
mam que chaves estrangeiras são mecanismos de restrição de integridade referencial que ga-
rantem que os valores que aparece em uma relação para um determinado conjunto de atributos
de uma tabela também devem aparecer em outra relação para um conjunto de atributos equi-
valente de outra tabela.
A Figura 15 apresenta uma ontologia como interface SERIN que exemplifica a utiliza-
ção da anotação ForeignURI. A ontologia define as classes “#Universidade” e “#Professor”;
além das propriedades “#endereco” e “#trabalha”. Essas propriedades estão anotadas respecti-
58
vamente com as anotações NotNull e ForeignURI. (Na Listagem 20 essa mesma ontologia é
apresentada em linguagem OWL).
Figura 15: Interface SERIN com os conceitos "#Universidade", "#Professor" e suas propriedades anota-
das com NotNull e ForeignURI.
A ontologia acima define apenas conceitos, i.e., classes e propriedades, mas não ins-
tâncias. Os exemplos a seguir comtemplam o caso onde as instâncias são mantidas em bases
de dados. Contudo, ao final dessa seção será apresentado o caso onde as instâncias são defini-
das na própria interface SERIN.
A Figura 16 ilustra dois cenários. Em ambos, a propriedade “#trabalha” liga “#Pedro”

a “#Unifor” — instâncias, respectivamente, das classes “#Professor” e “#Universidade”. Con-
tudo, no cenário 1 essa propriedade não possui a anotação ForeignURI para restringir que
apenas as instâncias mantidas na base de dados do host participem da relação “#trabalha”. A
ausência dessa anotação implica na suposição de mundo aberto, onde não há garantias de que
as instâncias existam ou estejam armazenadas na base. Portanto, a anotação ForeignURI pos-
sui uma semântica associada a suposição de mundo fechado localmente no host. O uso dessa
anotação desautoriza o serviço de dados semânticos de associar a instância “#Pedro” a qual-
quer instância de universidade que esta fora do host. Consequentemente, no exemplo do cená-
rio 1, não é possível efetuar as operações de atualização (PUT) ou deleção (DELETE) sobre a
instância “#Unifor” ou sobre suas propriedades por meio dos serviços de dados semânticos.
Figura 16: Propriedade #trabalha sem a anotação ForeignURI no cenário 1 e com a anotação no cenário 2.
A Listagem 18 apresenta dois exemplos de requisições HTTP não permitidas na au-

sência da anotação ForeignURI. Para essas requisições, o serviço de dados semânticos retorna
o código HTTP 405, Method Not Allowed, pois não é possível apagar a instância “#Unifor”
mediante a operação HTTP DELETE uma vez que não há garantias de que essa instância este-
59
ja armazenada no host. A operação HTTP PUT, sobre a propriedade “#endereco”, também

não é permitida, pois também não se pode atualizar uma propriedade cuja instância não se
encontre armazenada no host. Na verdade, não se pode garantir, no cenário 1 da Figura 16,
nem mesmo que “#Unifor” possua a propriedade “#endereco” explicitamente declarada. Pois,
apesar dessa propriedade possuir a restrição NotNull (linha 11 da Listagem 20), essa restrição
não será verifica para instâncias não presentes no host do serviço de dados semânticos. Por-
tanto, a instância “#Unifor” e os valores de suas propriedades são apenas de leitura no contex-
to do cenário 1.
1. DELETE /serin/interface.owl/Universidade/Unifor HTTP/1.1
Host: www.univA.br
2. PUT /serin/interface.owl/Universidade/Unifor/endereco HTTP/1.1

Host: www.univA.br
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="…">
<rdf:Description rdf:about="#Unifor">
<endereco>Av. Washigton Soares, 1321</endereco>
</rdf:Description>
</rdf:RDF>
Listagem 18: Requisições HTTP não permitidas na ausência da anotação ForeignURI.
É importante destacar que a requisição HTTP DELETE, mostrada na Listagem 19, so-
bre a propriedade “#trabalha” não é ilegal. Nesse caso o serviço de dados semânticos retorna
o código HTTP 200 OK, pois o comando irá remover apenas a relação que existe entre “#Pe-
dro” e “#Unifor”, mas não as instâncias. Apenas se “#trabalha” estivesse anotada com
NotNull esse comando seria ilegal.
DELETE /serin/interface.owl/Universidade/Pedro/trabalha HTTP/1.1

Host: www.univA.br
Listagem 19: Comando HTTP DELETE permitido sobre a propriedade “#trabalha”.
1 <owl:Class rdf:about="#Professor"/>
2 <owl:Class rdf:about="#Universidade"/>
3
4 <owl:ObjectProperty rdf:about="#trabalha">
5 <serin:foreignURI/>
7 <rdfs:range rdf:resource="#Universidade"/>
9
10 <owl:DatatypeProperty rdf:about="#endereco">
11 <serin:notNull/>
12 <rdfs:domain rdf:resource="#Universidade"/>
Listagem 20: Propriedade #trabalha anotada com ForeignURI e #endereco anotado com NotNull.
60
O modelo RDF foi concebido tendo em vista o ambiente aberto da Web, assim ele uti-
liza URIs para interligar instâncias dispostas em bases de dados diferentes e independentes
uma das outras. Esse modelo não impõe nenhum tipo de restrição condicionada à suposição
de mundo fechado localmente para as instâncias mantidas em um host, pois o RDF tem como
objetivo formar um imenso espaço global de dados interligados (HEATH; BIZER, 2011).
Contudo, existem situações onde é desejável um mecanismo de restrição de integridade refe-
rencial. Tal mecanismo se propõe a permitir que apenas instâncias mantidas em um host parti-
cipem das relações definidas na interface de serviço do host. Situações como, por exemplo, do
cenário 2 da Figura 16, onde apenas instâncias cadastradas no host da universidade A devem
estar interligadas entre si. Sem esse tipo de restrição não há como manter a consistência dos
dados, pois seria possível, por exemplo, associar professores da universidade B à universidade
A, o que não é o desejado.
Figura 17: Dois serviços de dados semânticos compartilhando a mesma interface SERIN.
A linguagem OWL permite definir um axioma de fechamento sobre uma propriedade

restringindo o seu contradomínio. Esse axioma consiste em uma restrição universal que atua
sobre a propriedade e que diz que ela só pode ser preenchida por instâncias de um tipo especi-
fico. Por exemplo, a ontologia Interface.owl da Figura 17 representa a interface SERIN com-
partilhada entre dois serviços de dados semânticos — representados pelos Hosts 1 e 2. Supo-
nha que se deseje que professores celetistas trabalhem exclusivamente em universidades par-
ticulares e que professores servidores trabalhem exclusivamente em universidades públicas.
De acordo com essa suposição é desejável que a instância “#Pedro” possa ser associada, por
meio da propriedade “#trabalha”, à instância “#Unifor”, mas não a instância “#UFC”, uma
vez que essa representa uma universidade pública. Contudo, a definição da propriedade “#tra-
61
balha”, na ontologia, permite que “#Pedro” se associe a uma universidade de qualquer tipo,
pois o contradomínio dessa propriedade é “#Universidade”.
Os axiomas de fechamento oferecem garantias de que a suposição adotada no exemplo

da Figura 17 seja sempre verdadeira. A Listagem 21 apresenta nas linhas 1 a 9 o axioma que
restringe que todo professor servidor trabalhe apenas em universidade públicas, enquanto que
as linhas 11 a 19 restringem que todo professor celetista trabalhe apenas em universidades
particulares. Ao final da listagem, as linhas 21 a 24 informam que os conjuntos das universi-
dades públicas e particulares são disjuntos, garantindo assim, que não haja caso algum onde a
mesma instância de professor possa estar associada a duas universidades de subclasses dife-
rentes. Porém, por meio de axiomas de fechamento não é possível restringir a localização de
uma instância, i.e., restringir que professores mantidos no host 1 só possam trabalhar nas uni-
versidades mantidas também no host 1. Assim, por exemplo, os axiomas da Listagem 21 não
proíbem que a instância “#Pedro” se ligue a instância “#PUC-Rio” (mostradas na Figura 17),
pois tal ligação não viola os axiomas. Contudo, essa ligação viola a suposição de mundo fe-
chado localmente definida para os serviços de dados semânticos.
1 <owl:Class rdf:about="#ProfessorServidor">
2 <rdfs:subClassOf rdf:resource="#Professor"/>
3 <rdfs:subClassOf>
4 <owl:Restriction>
5 <owl:onProperty rdf:resource="#trabalha"/>
6 <owl:allValuesFrom rdf:resource="#UniversidadePublica"/>
9 </owl:Class>
10
11 <owl:Class rdf:about="#ProfessorCeletista">
11 <rdfs:subClassOf rdf:resource="#Professor"/>
13 <rdfs:subClassOf>
14 <owl:Restriction>
15 <owl:onProperty rdf:resource="#trabalha"/>
16 <owl:allValuesFrom rdf:resource="#UniversidadeParticular"/>
19 </owl:Class>
20
21 <owl:Class rdf:about="#UniversidadeParticular">
22 <rdfs:subClassOf rdf:resource="#Universidade"/>
23 <owl:disjointWith rdf:resource="#UniversidadePublica"/>
24 </owl:Class>
Listagem 21: Axiomas de fechamento para as classes “#ProfessorServidor” e “#ProfessorCeletista”.
A anotação ForeignURI se propõe a restringir a localização das instâncias das proprie-

dades anotadas. Apenas instâncias controladas e mantidas pelo próprio host podem ser associ-
adas com esse tipo de propriedade. Não há limites para a quantidade de propriedades que po-
dem utilizar essa anotação, i.e., em uma mesma interface SERIN é possível haver várias pro-
62
priedades anotadas. Quanto mais propriedades forem anotadas, mais fechados e controlados
serão os dados do host.
A utilização da anotação ForeignURI também está prevista para o caso onde as instân-
cias associadas a propriedade anotada não estão na base de dados, mas definidas na própria
interface SERIN. Esse caso é bastante comum quando as instâncias de uma determinada clas-
se são poucas e mudam pouco ao longo do tempo. Um exemplo típico é a classe país — defi-
nida na Listagem 22. Uma vantagem de se definir o conjunto de instâncias de país diretamen-
te na interface SERIN é que dessa forma todos os hosts que adotarem a interface poderão re-
ferenciar exatamente as mesmas instâncias, não havendo, assim, duplicação de instâncias nas
bases de dados de cada host. Contudo, as interfaces SERIN não podem ser modificadas pelos
serviços de dados semânticos, consequentemente todas as instâncias definidas na interface são
apenas de leitura.
1 <owl:Class rdf:about="#Pais">
2 <owl:oneOf rdf:parseType="Collection">
3 <rdf:Description rdf:about="#EUA"/>
4 <rdf:Description rdf:about="#Italia"/>
5 <rdf:Description rdf:about="#Alemanha"/>
6 <rdf:Description rdf:about="#Brasil"/>
7 <rdf:Description rdf:about="#China"/>
8 <rdf:Description rdf:about="#Franca"/>
9 </owl:oneOf>
10 </owl:Class>
Listagem 22: Enumeração da classe Pais definida na interface SERIN.
Suponha que se deseje saber a nacionalidade dos professores universitários. Podería-

mos criar uma propriedade “#nacionalidade”, onde seu contradomínio fosse do tipo “#Pais”.
Para garantir que apenas os países definidos na Listagem 22 fossem válidos, então anotaría-
mos “#nacionalidade” com ForeignURI. Comandos POST, PUT ou DELETE que forem exe-
cutados pelo serviço de dados semânticos sobre essas instâncias devem retornar o código
HTTP 405, método não permitido.
Por último, é interessante frisar que essa anotação não implica na obrigatoriedade da
instância “#Pedro” ter a propriedade “#trabalha” definida explicitamente. No entanto, caso ela
esteja definida, então obrigatoriamente as instâncias do contradomínio devem estar definidas
na interface SERIN ou presentes na base de dados do host. Como é ilustrado no segundo ce-
nário da Figura 16 e na Figura 17.
63
4.3.5 Anotação Embedded
Todas as anotações apresentadas até esse ponto têm como principal característica vali-
dar a entrada de dados nos serviços de dados semânticos. Isso significa que as restrições de
integridade são verificadas sempre que uma operação de escrita de dados (POST, PUT e DE-
LETE) é executada. Diferentemente, a anotação Embedded não se propõe a fazer verificação
de integridade, pois ela está associada apenas à operação de leitura (HTTP GET). O propósito
dela é permitir que uma requisição GET executada para uma instância em particular retorne
tanto a instância requisitada, quanto as instâncias relacionadas a ela por meio de propriedades
Embedded. Essa anotação se diferencia da ForeignURI, pois ela indica ao serviço SDS quais
as instâncias que sempre devem ser visualizadas em conjunto pela requisição GET, enquanto
a anotação ForeignURI indica qual o conjunto de propriedades de uma instância que deve,
obrigatoriamente, ser armazenado na mesma base de dados da instância requisitada.
A anotação Embedded atua somente sobre instâncias, ela se aplica apenas às proprie-
dades do tipo owl:ObjectProperty, já que o contradomínio das propriedades
owl:DatatypeProperty é definido por tipos primitivos e não permitem associação com uma
instância. Para exemplificar o contexto onde essa anotação se aplica, suponha que se deseje
gerar um comprovante de matrícula como o apresentado na Listagem 23.
Listagem 23: Exemplo de comprovante de matrícula gerado para o primeiro semestre de 2014.
As informações exibidas nesse comprovante são oriundas de várias instâncias diferen-

tes. De maneira simplificada é razoável dizer que os campos: matrícula, nome, ingresso, curso
e turma são propriedades relativas à entidade aluno. Pois um aluno possui uma matrícula, um
64
nome, uma data de ingresso em determinado curso e está alocado em uma turma especifica
desse curso. Já os campos: código, nome da disciplina, crédito e horário são próprios da enti-
dade disciplina.
A Figura 18 mostra uma possível ontologia que define as entidades — e suas relações
— utilizadas para representar o comprovante da Listagem 23. Nessa figura a ontologia apre-
sentada atua como uma interface SERIN, onde as propriedades “#alunoMatriculado” e “#dis-
ciplinaMatriculada” estão anotadas com Embedded.
Figura 18: Possível ontologia para representar um comprovante de matrícula e suas entidades correlatas.
Suponha agora que as instâncias apresentadas na Figura 19 representem o comprovan-

te da Listagem 23. Assim, “#Hermano” é a instância do aluno que efetuou matrícula no pri-
meiro semestre de 2014 nas disciplinas: “#WebSemantica”, “#AspectosFormais” e “#Servi-
cosWeb”. A instância “#2014.1” representa o comprovante gerado no ato da matrícula.
Figura 19: O conjunto de instâncias que compõe um comprovante de matricula e a interface SERIN que o
define.
65
A anotação Embedded permite que o serviço de dados semânticos, ao receber uma re-
quisição HTTP GET para uma instância de comprovante, retorne sempre a instância requisi-
tada juntamente com suas instâncias embutidas, i.e., o aluno e suas disciplinas. A Figura 20
ilustra esse comportamento.
Figura 20: Requisição HTTP GET para uma instância com propriedades Embedded.
Na Figura 20, um agente efetua uma requisição HTTP GET a um serviço de dados
semânticos. Esse agente solicita o comprovante de matrícula “#2014.1”. No entanto, como as
propriedades “#alunoMatriculado” e “#disciplinaMatriculada” estão anotadas com Embedded,
todas as instâncias associadas ao comprovante, mediante essas propriedades, são retornadas
juntamente com ele. O retorno previsto pelo serviço de dados semânticos é exibido na Lista-
gem 25. A vantagem de se utilizar a anotação Embedded, é que com apenas uma requisição
HTTP GET é possível obter todas as instâncias necessárias para gerar o comprovante da Lis-
tagem 23. Sem essa anotação, por outro lado, seriam necessárias cinco requisições GET para a
obtenção das mesmas instâncias. A Listagem 24 apresenta as requisições necessárias na au-
sência dessa anotação.
1. GET /serin/interface.owl/Comprovante/2014.1 HTTP/1.1
Host: www.unifor.br
2. GET /serin/interface.owl/Aluno/Hermano HTTP/1.1

Host: www.unifor.br
3. GET /serin/interface.owl/Disciplina/WebSemantica HTTP/1.1

Host: www.unifor.br
4. GET /serin/interface.owl/Disciplina/ServicosWeb HTTP/1.1

Host: www.unifor.br
5. GET /serin/interface.owl/Disciplina/AspectosFormais HTTP/1.1

Host: www.unifor.br
Listagem 24: Requisições HTTP GET necessárias para se obter todas as informações relevantes de um
comprovante de matrícula sem o auxílio da anotação Embedded.
66
2 <rdf:RDF xmlns:rdf="…">
3 <Comprovante rdf:about="#2014.1">
4 <periodoLetivo>2014.1</periodoLetivo>
5 <emissor rdf:resource="#Unifor"/>
6 <matricula rdf:resource="#Hermano"/>
7 <atividade rdf:resource="#AspectosFormais"/>
8 <atividade rdf:resource="#ServicoWeb"/>
9 <atividade rdf:resource="#WebSemantica"/>
10 </Comprovante>
11
12 <Universidade rdf:about="#Unifor">
13 <nome>Universidade de Fortaleza</nome>
14 </Universidade>
15
17 <codigo>10001</codigo>
18 <turma>13</turma>
19 <ingresso>2011.1</ingresso>
20 <nome>Hermano Albuquerque Lira</nome>
21 <curso>Mestrado em Informática Aplicada</curso>
22 </Aluno>
23
24 <Disciplina rdf:about="#AspectosFormais">
25 <horario>3a 5a MANHÃ 7h30 às 9h10</horario>
26 <credito>4</credito>
27 <nome>ASPECTOS FORMAIS</nome>
28 </Disciplina>
29
30 <Disciplina rdf:about="#ServicoWeb">
31 <horario>6a NOITE 19h às 20h40</horario>
33 <nome>SERVIÇOS WEB</nome>
34 </Disciplina>
35
36 <Disciplina rdf:about="#WebSemantica">
38 <horario>4a NOITE 19h às 20h40</horario>
39 <nome>WEB SEMÂNTICA</nome>
40 </Disciplina>
41 </rdf:RDF>
Listagem 25: Resposta a requisição HTTP GET. Sem a anotação Embedded, o RDF retornado traria
apenas a instância “#2014.1” (descrita nas linhas 3 a 10).
Em razão da baixa granularidade do modelo RDF — ele representa os dados como tri-
plas (sujeito-predicado-objeto) — sua manipulação pode se tornar bastante complexa. Para
facilitar essa manipulação a anotação Embedded possibilita combinar instâncias de forma a se
obter uma representação com maior granularidade. O que é mais adequado em muitas situa-
ções como no exemplo do comprovante de matricula.
É interessante observar que a anotação Embedded não torna a propriedade obrigatória.

Assim, por exemplo, para garantir que um comprovante de matricula esteja associado explici-
67
tamente a um aluno via a propriedade “#alunoMatriculado”, além da anotação Embedded

também é fundamental a inclusão da anotação NotNull.
Por fim, a Listagem 26 apresenta a definição da propriedade “#disciplinaMatriculada”

com a anotação Embedded em destaque.
1 <owl:ObjectProperty rdf:about="#disciplinaMatriculada">
2 <serin:embedded/>
3 <rdfs:domain rdf:resource="#Comprovante"/>
4 <rdfs:range rdf:resource="#Disciplina"/>
Listagem 26 Propriedade “#disciplinaMatriculada” com a anotação Embedded.
4.3.6 Anotação Internal
O propósito da anotação Internal é restringir a criação de novas instâncias de uma de-

terminada classe. Instâncias de classes Internal só podem ser persistidas em um serviço de
dados semânticos como membros de uma entidade forte.
De maneira análoga ao modelo Entidade-Relacionamento, instâncias de classes Inter-

nal são como entidades fracas, portanto só podem existir na base de dados se participarem de
um relacionamento com uma entidade forte (a instância pai). Por exemplo, em uma ontologia
sobre cadastro de empregados e seus dependentes, uma instância de dependente só pode ser
mantida na base do host se estiver associada a uma instância de um empregado.
O SDS não permite que uma instância Internal seja persistida diretamente por uma re-
quisição HTTP POST. Sua adição deve ocorrer juntamente com a de sua instância pai, na
mesma requisição que a insere, ou então por meio de uma requisição HTTP PUT, adicionan-
do-a como um novo membro de uma instância já presente na base.
A importância da anotação Internal advém da necessidade de se persistir instâncias

fracas (ou dependentes) de maneira consistente. Em razão da manutenção dessa consistência,
uma requisição HTTP DELETE assinalada para uma determinada instância, força que o servi-
ço SDS remova, juntamente com ela, todas as suas dependências. A linguagem OWL não
trata esse tipo de restrição. Ela supõe que sempre podem existir instâncias incompletas ou
desconhecidas no conjunto. Portanto, o serviço de dados semânticos não deve permitir a exis-
tência de instâncias Internal órfãs, já que isso violaria o estado de consistência desejado para
a base de dados.
68
A anotação Internal não pretende tornar o conjunto fechado, i.e., outras instâncias po-
dem ser adicionadas a ele no futuro. Porém, com essa anotação, pretende-se garantir que um
conjunto mínimo de instâncias esteja explicitamente armazenado no host, de forma a manter o
conjunto todo consistente nos moldes da suposição de mundo fechado localmente.
Um exemplo típico da aplicabilidade da anotação Internal é para o contexto das ins-

tâncias de notas fiscais. A Figura 21 apresenta uma ontologia elaborada com base na especifi-
cação de nota fiscal eletrônica (“Sistema Nota Fiscal Eletrônica,” 2012). A classe “#NotaFis-
cal” possui quatro relações: “#emit” (que identifica o emitente da nota), “#dest” (que identifi-
ca o destinatário), “#det” (que detalha quais itens compõem a nota) e “#total” (que apresenta o
valor total declarado na nota).
Figura 21: Ontologia de um nota fiscal eletrônica com propriedades Embedded e classes Internal.
Instâncias das classes “#Emitente”, “#Destinatario” e “#Produto” já devem existir pre-

viamente na base de dados de um serviço de dados semânticos, e tais instâncias são simples-
mente associadas a uma nova nota fiscal instanciada. Contudo, esse não é o caso das instân-
cias de “#Item” ou “#Total”, pois as instâncias dessas classes não podem ser criadas nem an-
tes nem depois de uma nota fiscal, mas ao mesmo tempo. Essas instâncias são dependentes de
nota fiscal. Se um item fosse criado antes de uma nota fiscal ele seria órfão, o que representa-
ria uma inconsistência semântica, pois não pode existir item sem uma nota fiscal associada.
Por outro lado, se ele fosse criado depois da nota fiscal também haveria uma inconsistência,
pois uma nota fiscal não pode existir sem pelo menos um item associado a ela.
As classes “#Item” e “#Total” devem possuir a anotação Internal, como ilustrado na

Figura 21. Essa anotação informa ao serviço de dados semânticos que instâncias dessas clas-
ses são dependentes da instância de nota fiscal e assim não podem ser criadas diretamente via
uma requisição POST.
69
1. POST /serin/interface.owl/Item/01 HTTP/1.1

Host: www.univA.br
2. POST /serin/interface.owl/Total/02 HTTP/1.1

Host: www.univA.br
Listagem 27: Requisições POST não permitidas, pois classes com anotação Internal não pode ser
instânciadas diretamente.
Para que as notas fiscais criadas em um serviço de dados semânticos sejam consisten-
tes, a requisição POST que instancia a nota fiscal também deve instanciar todos os seus itens,
bem como o total. Uma requisição POST válida é apresentada na Listagem 28.
1 POST /serin/interface.owl/NotaFiscal/10567 HTTP/1.1

2 Host: www.sefaz.gov.br
3
5 <rdf:RDF xmlns="...">
6 <NotaFiscal rdf:about="#10567">
7 <dataCompra>2014-02-06T11:32:00</dataCompra>
8 <emit rdf:resource="#Livraria_Saraiva"/>
9 <dest rdf:resource="#Hermano"/>
10 <det rdf:resource="#10567-01"/>
13 <total rdf:resource="#TOT10567"/>
14 </NotaFiscal>
15
16 <Item rdf:about="#10567-01">
17 <valorItem>150.0</valorItem>
18 <prod rdf:resource="#prod01"/>
19 </Item>
20
21 <Item rdf:about="#10567-02">
24 </Item>
25
26 <Item rdf:about="#10567-03">
29 </Item>
30
31 <Total rdf:about="#TOT10567">
32 <valorTotal>439.0</valorTotal>
33 </Total>
34 </rdf:RDF>
Listagem 28: Comando HTTP POST válido para criação de uma nova nota fiscal.
As restrições impostas pela anotação Internal para a persistência de novas instâncias,

atuam como um mecanismo, ainda que insipiente, de controle de transação. Pois, o conjunto
de instâncias vinculadas entre si por meio dessa anotação apenas podem ser criadas, removi-
das ou lidas como um bloco único e indivisível, i.e., de forma atômica. Essa anotação é um
importante mecanismo que contribui para a criação de instâncias complexas e que devem atu-
ar como um indivíduo único e bem definido dentro do host onde é mantido.
70
4.3.7 Escopo das anotações
A Tabela 3 apresenta o escopo das anotações de restrição de integridade quanto ao tipo

de recurso sobre o qual as anotações se aplicam. As anotações ForeignURI e Embedded são
exclusivas das propriedades owl:ObjectProperty. A anotação Id é exclusiva para propriedades
owl:DatatypeProperty, as anotações NotNull e Unique são permitidas para ambos os tipos de
propriedades e, por último, a anotação Internal é exclusiva para a utilização em classes.
Tabela 3: Relação entre as anotações e os tipos de propriedade.
Anotações owl:DatatypeProperty owl:ObjectProperty owl:Class

NotNull X X -
Unique X X -
Id X - -
ForeignURI - X -
Embedded - X -
Internal - - X
4.4 Sumário
Neste capítulo, apresentou-se a definição das anotações de restrição de integridade

propostas para estender a interface SERIN. Mostrou-se a semântica de cada anotação e como
elas se aplicam aos conceitos definidos na interface.
Apresentaram-se as vantagens dessas anotações em relação à linguagem OWL. Tais

anotações oferecem mecanismos de integridade de dados de acordo com a suposição de mun-
do fechado localmente.
No próximo capítulo apresenta-se uma arquitetura que implementa o mecanismo de

processamento dessas anotações e mostra-se como esse mecanismo se integra aos serviços de
dados semânticos.
Capítulo 5
5
Uma arquitetura para serviços de dados

semânticos
Este capítulo apresenta uma arquitetura de software para suportar os serviços de da-
dos semânticos. A arquitetura é descrita por meio da apresentação dos seus componentes e
do relacionamento entre eles. Este capítulo também apresenta uma implementação da arqui-
tetura baseada na linguagem Java
5.1 Introdução
O conceito de arquitetura de software pode ser definido como uma configuração de

elementos arquiteturais — componentes, conectores e dados — restringidos nas suas relações
a fim de conseguir um conjunto desejado de propriedades arquiteturais (FIELDING, 2000).
Enquanto o conceito de estilo arquitetural é definido como um conjunto coordenado de res-
trições arquiteturais que restringem os papéis e funções dos elementos arquiteturais e as rela-
ções permitidas entre esses elementos dentro de qualquer arquitetura que esteja de acordo com
esse estilo (FIELDING, 2000).
Baseado nos conceitos definidos acima, o capítulo 3 deste trabalho propôs os serviços
de dados semânticos (SDS), uma abordagem aderente ao estilo arquitetural REST, para cons-
trução de serviços de dados interligados. Um importante componente dessa abordagem é a
interface SERIN, a qual foi estendida no capítulo 4 para que permitisse a verificação da inte-
gridade dos dados mantidos pelo serviço SDS.
Assim, o objetivo deste capítulo é apresentar uma possível arquitetura que propicie a
construção de serviços SDS. Essa arquitetura deve, portanto, ler e interpretar a interface SE-
RIN, bem como suas anotações, gerenciando as requisições HTTP feitas ao serviço e verifi-
cando a integridade de dados de acordo com as regras estabelecida na interface. Essa arquite-
72
tura será dividida em três componentes principais: o primeiro responsável por processar as
requisições HTTP, o segundo responsável por verificar a integridade dos dados e o terceiro
responsável por abstrair a base de dados.
5.2 Implementação da Arquitetura
Neste trabalho, adotou-se a linguagem Java para a implementação dos serviços de da-
dos semânticos. Outras linguagens poderiam ter sido utilizadas para a implementação do SDS,
pois a arquitetura aqui definida é independente de plataforma ou linguagem de programação.
Contudo, a linguagem Java foi escolhida por ser madura e por possuir um grande conjunto de
frameworks que auxiliam a implementação. Dentre esses frameworks, destacam-se: o RES-
TEasy13 e o Jena14. O primeiro tem como finalidade auxiliar o desenvolvedor na construção
de serviços Web RESTful, enquanto o segundo fornece parsers para as linguagens RDF e
OWL, além de uma API para execução de inferências e um motor de busca SPARQL.
O RESTEasy é um projeto de código aberto da JBoss Community15 e foi projetado pa-

ra ser integrável em qualquer contêiner Servlet, contudo ele já vem integrado nativamente ao
servidor de aplicação JBoss 7; e em razão disso, esse foi o contêiner utilizado como platafor-
ma para a implementação do servidor SDS. Já o Jena foi um dos primeiros frameworks a sur-
gir para auxiliar na construção de aplicações de dados interligados. Originalmente, ele era um
projeto de pesquisa interno da Hewllet-Packard (HP). Contudo, após sua primeira versão, a
empresa decidiu torná-lo código aberto. Desde então, ele tem sido utilizado como base para
uma vasta gama de aplicações comerciais e de pesquisa. Atualmente, seu código é mantido e
evoluído pela fundação Apache16. Ele implementa as principais especificações propostas pela
W3C para os padrões da Web Semântica. Em razão de sua larga adoção, assim que novas es-
pecificações da são propostas, esse framework é rapidamente atualizado e por esse motivo, ele
foi adotado para a implementação do servidor SDS.
A Figura 22 mostra um diagrama de implantação dos artefatos apresentados acima e

suas relações. O servidor SDS foi empacotado fisicamente no arquivo SDSServer.war. Ele
utiliza as APIs do Jena para trabalhar com documentos OWL e RDF, assim como estende a
13
http://resteasy.jboss.org
14
http://jena.apache.org
15
http://www.jboss.org
16
http://www.apache.org
73
infraestrutura provida pelo framework RESTEasy para monitorar e processar as requisições

HTTP de seus clientes.
Figura 22: Diagrama de implantação de um servidor SDS no servidor de aplicação JBoss 7.
O servidor SDS reconhece os métodos HTTP GET, POST, PUT e DELETE e os inter-
preta de acordo com a semântica padrão estabelecida na especificação do próprio protocolo
HTTP (FIELDING et al., 1999). A Tabela 4 mostra essa semântica. Toda a comunicação en-
tre um cliente e o servidor precisa acontecer por meio desses quatro métodos. Contudo, o ser-
vidor SDS implementado neste trabalho também responde aos métodos HEAD e OPTIONS.
Isso acontece por que a utilização do framework RESTEasy fornece implementações padrão
para os dois métodos e como eles são idempotentes, não foram suprimidos ou redefinidos no
servidor.
Tabela 4: Semântica padrão dos métodos HTTP.
Método HTTP Descrição

GET Recupera um recurso
POST Cria um novo recurso
PUT Atualiza um recurso
DELETE Exclui um recurso
Um servidor SDS pode ser configurado para reconhecer uma ou mais interfaces SE-
RIN, e é por meio dessas interfaces que ele verifica se os dados que um cliente deseja ler, ou
escrever, são adequados à base mantida pelo serviço. A Figura 23 mostra a interação entre um
cliente e um serviço que mantém dados referentes ao domínio de conhecimento de uma uni-
versidade, via interface Universidade.owl.
74
Figura 23: Toda informação lida ou escrita na base de dados precisa respeitar o domínio de conhecimento
estabelecido na interface Universidade.owl.
Internamente, o servidor SDS é composto por em três componentes. A comunicação

entre eles ocorre tipicamente como ilustrado na Figura 24.
Figura 24: Componentes do servidor SDS em um cenário de processamento de uma requisição HTTP.
O componente processador de requisições obtém uma requisição HTTP de um cliente

(passo 1) e verifica as anotações HTTP permitidas na interface (passo 2). Ele encaminha,
então, o conteúdo da requisição para o componente verificador de integridade de dados (pas-
so 3). Esse componente, por sua vez, analisa a integridade do documento RDF passado no
corpo da requisição HTTP, verificando novamente na interface SERIN (passo 4) quais as
restrições de integridade definidas. O componente verificador de integridade de dados retorna
ao processador de requisições o resultado da análise efetuada (passo 5), que então repassa ao
componente de persistência (passo 6) os dados validados para atualizar a base de dados. Por
fim, o componente de persistência retorna o resultado da atualização da base ao processador
de requisições (passo 7), e esse retorna o resultado da requisição HTTP ao cliente (passo 8).
75
O componente processador de requisições atua, portanto, como um mediador, evitan-

do o acoplamento entre o componente que sabe verificar integridade de dados e o que sabe
como armazenar esses dados na base. Esse isolamento é importante, pois permite definir re-
gras de integridade sem que elas dependam da estrutura da base.
A Figura 25 mostra um diagrama de pacotes e destaca quais grupos de pacotes com-

põem cada um dos componentes do servidor SDS. Além disso, essa figura mostra claramente
as dependências que existem dos componentes entre si e deles com os frameworks adotados.
O pacote util apresentado possui apenas classes utilitárias, como leitores de stream de dados e
parsers de objetos para XML. Cada um dos componentes será descrito em mais detalhes nas
próximas seções, quando serão apresentados aspectos relevantes de projeto e implementação
de cada um deles.
Figura 25: Diagrama de pacotes do servidor SDS.
5.2.1 Componente Processador de Requisições
O componente Processador de Requisições tem como objetivos verificar qual o méto-

do HTTP (GET, POST, PUT ou DELETE) foi invocado pelo cliente, verificar se a URL sub-
metida segue a convenção de endereçamento estabelecida para um serviço SDS (seção 3.3.5),
e, por último, verificar se a interface SERIN informada na requisição é conhecida pelo servi-
76
dor SDS. Esse componente é composto por dois pacotes: endpoint e requesthandler.
O primeiro aloja a classe SDSAddressConventionHandler, cuja função é verificar se a
URL submetida está sintaticamente correta; e a partir dessa URL, verificar se a interface SE-
RIN que descreve o documento RDF submetido é reconhecida pelo servidor SDS. O segundo
pacote mantém a classe SDSRequestHandler, cuja função é mediar e controlar a comuni-
cação entre os outros componentes, i.e., decidir se a requisição HTTP deve passar pelo verifi-
cador de integridade (no caso de requisições de escrita) ou se vai direto para o componente de
persistência (caso de requisições de leitura). A Figura 26 mostra essas classes e seus princi-
pais métodos públicos.
Figura 26: Componente Processador de Requisições com seus pacotes e principais classes.
Toda requisição HTTP inicialmente é interceptada pelo framework RESTEasy. Ele,

contudo, instancia para cada requisição um novo objeto SDSAddressConventionHan-
dler para tratar tal requisição. A Figura 27 mostra uma requisição HTTP para obtenção da
instância RDF do aluno de matrícula 10001.
Figura 27: Diagrama de sequência de uma requisição HTTP GET sendo processada.
77
5.2.2 Componente Verificador de integridade de dados
O componente Verificador de integridade de dados é acionado sempre pelo Processa-

dor de requisições com o objetivo de validar a integridade dos dados recebidos no corpo de
uma requisição HTTP. Tais dados são verificados tanto sintaticamente, quanto semanticamen-
te. Por verificação sintática, entende-se que os dados estão serializados em um documento
RDF com sintaxe válida, e.g., RDF/XML. Por verificação semântica, entende-se que o conte-
údo do documento está satisfazendo a todas as restrições de integridade estabelecidas na inter-
face SERIN e que a URL da requisição identifica corretamente o documento.
O Verificador de integridade de dados é composto por dois pacotes: interfacema-

nager e integrityconstraint. O primeiro aloja a classe SERINManager, enquanto
o segundo mantém a classe SDSIntegrityConstraintHandler e a interface DBHan-
dler. A Figura 28 ilustra essas estruturas e seus principais métodos públicos.
Figura 28: Componente Verificador de Integridade de Dados com seus pacotes e principais classes.
A função da classe SERINManager é gerenciar as interfaces SERIN utilizadas pelo

servidor SDS. Essa classe conhece a localização (URL) de todas as interfaces relevantes ao
servidor, além de ser de sua responsabilidade verificar para cada interface quais classes pos-
suem as anotações Get, Post, Put e Delete. É ela, portanto, quem informa ao componente
Processador de requisições se uma requisição HTTP GET, POST, PUT ou DELETE é válida
para determinada interface SERIN. Além disso, a classe SERINManager também verifica se
as novas instâncias a serem inseridas no host do serviço possuem suas classes e propriedades
definidas na interface, evitando, assim, a inserção de informações que não pertençam ao do-
mínio de conhecimento definido para o serviço de dados semânticos.
78
A classe SDSIntegrityConstraintHandler é responsável por monitorar as

anotações NotNull, Unique, Id, ForeignURI, Embedded e Internal presentes na interface SE-
RIN. Portanto, sua função é verificar a cada requisição HTTP, se os dados se mantêm consis-
tentes na base de dados do host. Essa classe não possui acesso direto à base de dados (nem
tem acesso ao componente de Persistência), assim a verificação de restrições como Unique e
ForeignURI, que necessitam checar informações mantidas na base, são feitas por meio de
uma estrutura auxiliar, uma instância da interface DBHandler. Essa instância é injetada no
componente Verificador de Integridade de Dados pelo componente Processador de Requisi-
ções, através do método checkIntegrityConstraint da classe SERINManager e repassado
então para a instância de SDSIntegrityConstraintHandler, como pode ser observa-
do na Figura 29.
Figura 29: Diagrama de sequência mostrando a troca de mensagens entre as duas principais classes do
componente Verificador de Integridade de Dados.
5.2.3 Componente Persistência
O componente Persistência é acionado pelo Processador de requisições sempre que

for necessário ler ou escrever alguma informação na base de dados do host. Esse componente
79
tem como objetivo abstrair os mecanismos de persistência utilizados pelo servidor SDS. Essa
abstração possibilita persistir as informações sem haver um forte acoplamento entre a imple-
mentação do servidor SDS e o meio físico para persistência dos dados. Possíveis meios físicos
são os bancos de dados relacionais, os repositórios de grafos ou arquivos aderentes ao modelo
RDF. Neste trabalho adotou-se o framework Jena como base para a implementação do com-
ponente Persistência, no entanto, esse componente pode ser utilizado também com outros
frameworks.
A escolha do Jena se deve a dois importantes submódulos que ele possui para provi-
mento de acesso e armazenamento de dados: o SDB17 e o TDB18. O primeiro fornece uma
API para acesso a diversos bancos de dados relacionais (e.g., MySQL, Postgres, Oracle, SQL
Server, etc), permitindo o mapeamento dos elementos do modelo relacional (e.g., tabelas e
relações) com a estrutura de um grafo RDF. Contudo, a equipe de desenvolvedores do Jena
não pretende evoluir mais esse submódulo e recomenda que para novos projetos adote-se o
TDB. Esse submódulo, por sua vez, é a implementação de um Triple Store, i.e., um banco de
dados não relacional que persiste os dados diretamente como grafos RDF. De acordo com a
equipe do Jena, o TDB possui um desempenho melhor em relação ao SDB. A Figura 30 mos-
tra uma visão geral da arquitetura do Jena e sua relação com seus submódulos.
Figura 30: Visão geral da arquitetura do framework Jena.
17
http://jena.apache.org/documentation/sdb/index.html
18
http://jena.apache.org/documentation/tdb/index.html
80
O componente Persistência proposto neste trabalho é bastante simples, sendo compos-

to apenas pelo pacote persistence. A principal classe mantida por nesse pacote é a DB,
que encapsula toda a API do Jena para acesso e persistência de dados. A Figura 31 ilustra essa
classe e seus principais métodos públicos.
Figura 31: Componente Persistência com seu pacote e classe DB.
A Figura 32 ilustra o tráfego de dados desde a requisição acionada por um cliente até
sua persistência em uma base de dados gerenciada ou pelo SDB ou pelo TDB.
Figura 32: Camada de persistência implementada via framework Jena e submódulos SDB ou TDB.
Na próxima seção será apresentado um exemplo onde é bastante relevante a aplicação

dos serviços de dados semânticos (SDS).
81
5.3 Um cenário para o uso do SDS
Para exemplificar claramente a relevância dos serviços de dados semânticos (SDS),

faz-se necessário contextualizar primeiramente um cenário onde existe atualmente uma forte
demanda por dados interligados, e ao mesmo tempo, uma necessidade implícita de que esses
dados sejam tão completos e consistentes quanto possível.
Em 2011 foi lançada a Open Government Partnership (OGP), uma iniciativa interna-
cional entre diversos governos com a pretensão de difundir e incentivar globalmente práticas
governamentais relacionadas à transparência dos governos, ao acesso à informação pública e à
participação social. Oito países fundadores da parceria (África do Sul, Brasil, Estados Unidos,
Filipinas, Indonésia, México, Noruega e Reino Unido) assinaram a declaração de governo
aberto19 e apresentaram seus planos de ação. Atualmente, 64 países integram a parceria20.
Em confluência com este movimento político, a comunidade de Tecnologia da Infor-

mação tem avaliado e desenvolvido novas tecnologias adequadas para o livre acesso e a dis-
tribuição de dados por meio da Web. Dois importantes requisitos que essas tecnologias devem
possuir são: 1) Poder ser indexada e encontrada na Web; e 2) Estar em um formato aberto e
estruturado, e assim, compreensível por máquina.
Hoje, em razão do OGP, diversos portais de dados governamentais podem ser livre-
mente consultados via Web. O governo norte americano, por exemplo, publica seus dados em
www.data.gov, enquanto o reino unido publica em www.data.gov.uk e o Brasil dá
publicidade a seus dados por meio do portal www.dados.gov.br. Essencialmente, esses
portais disponibilizam conjuntos de bases de dados sobre educação, agricultura, clima, eco-
nomia, saúde, emprego, ciências e pesquisas, enfim, tudo que possa ser de interesse para o
cidadão. Tais portais se propõem a centralizar os dados produzidos pelos vários órgãos e esfe-
ras que compõem o governo de uma nação. Assim, é de responsabilidade de cada órgão, pu-
blicar seus dados.
Contudo, a grande maioria dos dados encontrada nesses portais ainda está representada
em formatos pouco amigáveis para processamento por máquinas; dificultando a análise, inte-
gração e inferências sobre eles. Dentre os formatos mais populares pode-se citar o HTML, o
19
http://www.cgu.gov.br/governoaberto/a-ogp/ogp-declaracao-de-governo-aberto.pdf
20
http://www.opengovpartnership.org/
82
XML, o PDF, o CSV, o ZIP, o DOC, o XLS, entre outros. O RDF que é um formato mais
alinhado com os princípios dos dados abertos, por exemplo, representa apenas duas bases de
dados, dentre todas as 238 bases catalogadas no portal brasileiro21.
Outra limitação bastante significativa com relação a esses portais diz respeito à falta
de uma API para consultar e atualizar os dados. O acesso esses dados pelo cidadão é feito por
meio de dump (Seção 2.3.2), i.e., o cidadão faz o download de um arquivo contendo todas as
informações de uma determinada base de dados. Essa abordagem possui algumas limitações,
como por exemplo, a impossibilidade de se consultar apenas uma parte da informação a qual
se está interessando sem precisar baixar a base inteira. Outra limitação, por parte dos órgãos
que atualizam os dados, é que não há como escrever novos dados na base, sem que se faça um
novo upload de toda a base.
O portal de dados do Reino Unido, assim como o portal brasileiro, também possui a
minoria de suas bases de dados em RDF, contudo, para essas bases foi disponibilizada uma
API de acesso, a Linked Data API22, cujo principal objetivo é permitir a navegação e a con-
sulta de dados sem a necessidade de se fazer um dump da base inteira.
Possivelmente, a falta de bases de dados no formato RDF está relacionada à falta de

vocabulários e ontologias adequadas para descrever os dados no contexto do governo. Tendo
em vista isso como a causa da carência de bases RDF, o governo brasileiro está trabalhando
no e-VoG23 (Vocabulários e Ontologias do Governo Eletrônico). O e-VoG pretende ser um
conjunto de padrões, ferramentas e metodologias para possibilitar: o intercâmbio de informa-
ções com acordo semântico, de forma a viabilizar o pronto cruzamento de dados de diversas
fontes; o uso de metodologias de modelagem conceitual como forma de elicitação do conhe-
cimento tácito das áreas de negócio de governo; o uso de ontologias como ferramenta para
explicitar conhecimentos de maneira formal e coerente; e o alinhamento conceitual das diver-
sas áreas do conhecimento do governo.
Embora o e-VoG já tenha produzido algumas ontologias, e várias outras estejam em

desenvolvimento, a especificação de APIs para consultar e atualizar os dados descritos por
elas não é tratado sob nenhum aspecto. Assim, a próxima seção deste trabalho irá ilustrar a
utilização dos serviços SDS como uma maneira de preencher essa lacuna.
21
http://dados.gov.br/dataset
22
https://code.google.com/p/linked-data-api/
23
http://vocab.e.gov.br/
83
5.4 Exemplo de uso do SDS
Esta seção apresenta a aplicação da arquitetura para serviços de dados semânticos

(SDS) sobre uma ontologia definida pelo e-VoG. A ontologia escolhida foi a que descreve a
classificação das despesas do orçamento federal brasileiro24, ilustrada na Figura 33.
Figura 33: Ontologia de classificação das despesas do orçamento federal brasileiro.
24
http://vocab.e.gov.br/2013/09/loa
84
A partir da ontologia mostrada na Figura 33, que pode ser encontrada em formato
OWL no endereço http://vocab.e.gov.br/2013/09/loa.owl, a construção de
um serviço SDS é bastante simples. Inicialmente, devem ser acrescentadas as anotações Get,
Post, Put e Delete nessa ontologia. Essas anotações informam quais operações serão permiti-
das sobre os dados. Em seguida, devem ser acrescentadas também as anotações de restrição
de integridade (NotNull, Unique, Id, ForeignURI, Embedded e Internal) para garantir dados
completos e consistentes sobre o orçamento federal. Feitas as devidas anotações na ontologia
loa.owl, ela estará pronta para assumir o papel de uma interface SERIN perante um servi-
dor SDS.
A ontologia loa.owl mantém apenas conceitos sobre o domínio de conhecimento de

orçamento federal. Isso corrobora com a visão deste trabalho sobre a separação do conheci-
mento (Seção 3.3.1), onde os dados sobre o orçamento não devem fazer parte da ontologia de
orçamento. Atualmente, os dados orçamentários estão publicados em arquivos RDF zipados e
disponíveis para baixar em www.dados.gov.br/dataset/orcamento-federal.
Para tornar tais dados acessíveis por meio de um serviço SDS basta implantar o servidor SDS
em um host qualquer, e depois popular sua base com os dados providos dos arquivos RDF.
Por “host qualquer”, enfatiza-se o fato de que a interface SERIN é abstrata e, portanto,
não se vincula a nem um serviço SDS. Contudo, bons candidatos para hosts do serviço SDS
de orçamento federal são os hosts dados.gov.br e o vocab.e.gov.br. Além desses,
outros possíveis bons candidatos são os portais mantidos pelos órgãos que compõem o gover-
no, por exemplo, portais ministeriais que são responsáveis por elaborar parcelas (de acordo
com as suas competências) do orçamento federal.
É interessante notar que a abordagem dos serviços SDS pode ser implementada para
os dados do orçamento federal de, pelo menos, duas maneiras distintas. A primeira, ilustrada
na Figura 34, é implantando-se o serviço no host dados.gov.br, e a segunda, mostrada na
Figura 35, é implantando-se vários serviços, um em cada host de órgão competente que parti-
cipa da elaboração do orçamento.
85
Figura 34: Serviço de dados semânticos implantado no host dados.gov.br.
Figura 35: Serviços de dados semânticos implantados nos hosts dos órgãos do governo.
Na abordagem mostrada na Figura 34 é responsabilidade de cada órgão escrever novos

dados e atualizar os existentes no host dados.gov.br via o serviço SDS. Assim, nessa
abordagem os órgãos são clientes do serviço SDS. Já na Figura 35 os próprios órgãos são ser-
viços SDS e host dados.gov.br não tem mais função alguma dentro da arquitetura SDS, a
não ser atuar restritamente como um catalogo, indicando aonde encontram-se as bases de da-
dos orçamentárias de cada órgão. Ambas as abordagens possuem características diferentes.
Enquanto na primeira abordagem os dados de todos os órgãos ficam centralizados em um
único host, na segunda abordagem esses dados tornam-se distribuídos, sendo mantidos pelos
próprios órgãos que os produzem. Contudo, nas duas abordagens sempre há a presença da
interface SERIN, i.e., a ontologia loa.owl, que atua como um esquema dos dados, descre-
86
vendo que tipo de informações podem ser encontradas nos hosts e garantindo por meio de
suas anotações quais dados podem ser acessados e escritos, além de como os dados devem ser
escritos corretamente.
A abordagem da Figura 35 ilustra bem o potencial dos serviços SDS e da interface

SERIN, pois fica claro a intenção de se construir serviços de dados que sejam descritos por
uma interface semântica compartilhável entre vários hosts. Cada host mantém dados próprios
de seus órgãos, mas todos seguem os conceitos definidos pela mesma ontologia. Uma impli-
cação direta dessa abordagem é a não necessidade de algoritmos de matching para fazer ca-
samentos semânticos entre ontologias.
5.5 Sumário
Neste capítulo, foi mostrada a arquitetura de um serviço de dados semânticos, além de

ilustrado como esse serviço pode ser utilizado no contexto de publicação de dados governa-
mentais. Por fim, foi implementado um protótipo para a avaliação dessa arquitetura e tal im-
plementação está disponível no endereço www.activeontology.com.br.
No próximo capítulo, será apresentada uma comparação entre abordagens de serviços

de acesso a dados em comparação com a abordagem SDS.
Capítulo 6
6
Análise Comparativa com os Serviços de

Dados Semânticos
Este capítulo avalia a abordagem dos Serviços de Dados Semânticos (SDS) por meio
de uma análise comparativa entre ela e outras abordagens similares.
6.1 Introdução
O capítulo 2 introduziu, resumidamente, os trabalhos: Open Data Protocol (OData),

Linked Data Services (LIDS), Linked Data Platform (LDP) e SPARQL 1.1 Protocol. Neste
capítulo, esses trabalhos serão apresentados com maiores detalhes, para possibilitar uma aná-
lise e comparação deles com os Serviços SDS. Discutem-se aqui as principais vantagens e
limitações dessas abordagens em relação à abordagem SDS. Assim, pretende-se mostrar os
benefícios dos serviços SDS em seus principais aspectos.
6.2 Metodologia
A metodologia de avaliação deste trabalho consiste em, primeiramente, apresentar as

principais abordagens na área de serviços de acesso a dados, para em seguida efetuar uma
análise comparativa qualitativa entre o SDS e essas abordagens.
A hipótese considerada neste trabalho é a de que nas principais abordagens de serviços

de dados o suporte à escrita fica penalizado pela falta de mecanismos de verificação e garantia
de integridade de dados. Outra hipótese assumida é que em diversos cenários do mundo real é
mais apropriada a utilização da semântica de mundo fechado localmente para esses serviços.
Para possibilitar a comparação, cada abordagem é descrita em relação a quatro aspec-

tos: 1) O suporte ao modelo de dados RDF, que define que o serviço envia e recebe dados por
88
meio de um modelo formal para representação de dados interligados. 2) O suporte à escrita

de dados, que é a capacidade que o serviço tem de receber requisições para inclusão de novos
dados na base de seu host. 3) O suporte à verificação de integridade, que diz respeito à capa-
cidade do serviço manter a base de dados do host em um estado íntegro a cada requisição de
escrita. Assegurando, assim, a consistência dos dados ao longo de diversas transições entre
estados. E por último, 4) a disposição de uma interface de serviço, que define um contrato
entre o serviço e seus clientes, indicando que tipo de dados e de operações são permitidas para
aquele serviço. Tais aspectos permitem avaliar as vantagens e limitações que cada abordagem
oferece ao cenário de acesso e manipulação de dados interligados via serviços Web.
Nas próximas seções as principais abordagens de serviços de dados são apresentadas

em relação aos aspectos expostos acima.
6.3 Open Data Protocol (OData)
O Open Data Protocol (PIZZO; HANDL; ZURMUEHL, 2014a), ou OData, é uma es-
pecificação para construção de serviços Web RESTful de consulta e atualização de dados. Ele
fornece uma maneira uniforme para consultar e manipular conjuntos de dados por meio de
operações de CRUD. Esses dados estão representados no modelo Entity Data Model (EDM)
(PIZZO; HANDL; ZURMUEHL, 2014b), um modelo baseado no de Entidade-
Relacionamento (CHEN, 1976), e que estende seus usos tradicionais para o contexto da Web.
6.3.1 Suporte ao modelo de dados RDF
A abordagem OData adota somente o modelo EDM e propõe serializar seus dados nos
formatos Atom (ZURMUEHL; PIZZO; HANDL, 2013) e JSON (HANDL; PIZZO;
BIAMONTE, 2014). O EDM é uma representação de estruturas de dados como entidades e
relacionamentos inspirada no modelo relacional. Para ilustrar como os dados são representa-
dos esse modelo, vamos utilizar o serviço TripPin. Esse é um serviço de demonstração que
está disponível online na página de documentação 25 do OData. Ele pode ser acessado por
meio da URL http://services.odata.org/V4/TripPinServiceRW.
25
http://www.odata.org
89
No modelo EDM é possível definir tipos para os dados. O serviço TripPin, por exem-
plo, define o tipo People, entre outros. A Listagem 29 apresenta os dados retornados por esse
serviço ao se executar a requisição HTTP GET para a URL
http://services.odata.org/V4/TripPinServiceRW/People.
1 {
2 ”@odata.context”: “serviceRoot/$metadata#People”,
3 “value”: [
4 {
5 “@odata.id”: “serviceRoot/People('russellwhyte')”,
6 “UserName”: “russellwhyte”,
7 “FirstName”: “Russell”,
8 “LastName”: “Whyte”,
9 “Emails”: [
10 “Russell@example.com”,
11 “Russell@contoso.com”
12 ],
13 “AddressInfo”: [
14 {
15 “Address”: “187 Suffolk Ln.”,
16 “City”: {
17 “CountryRegion”: “United States”,
18 “Name”: “Boise”,
19 “Region”: “ID”
20 }
21 }
22 ],
23 “Gender”: “Male”
24 },
25 {
26 “@odata.id”: “serviceRoot/People('keithpinckney')”,
27 “UserName”: “keithpinckney”,
28 “FirstName”: “Keith”,
29 “LastName”: “Pinckney”,
30 “Emails”: [
31 “Keith@example.com”,
32 “Keith@contoso.com”
33 ],
34 “AddressInfo”: [],
35 “Gender”: “Male”
36 }
37 ]
38 }
Listagem 29 Coleção de instâncias do tipo People.

A Listagem 29 apresenta uma coleção composta por duas instâncias do tipo People. A
primeira instância está definida entre as linhas 4 e 24, enquanto a segunda está entre as linhas
25 e 36. Na linha 2 dessa listagem é informado o contexto, isso é, de que tipo são as instâncias
da coleção. Cada instância possui um identificador único, que pode ser observado nas linhas 5
e 26. Além desses identificadores, cada instância é composta por pares de propriedades e va-
lores. Nesse exemplo os dados foram serializados em JSON (HANDL; PIZZO; BIAMONTE,
90
2014), mas também é possível utilizar os serviços OData com os dados representados no for-
mato Atom (ZURMUEHL; PIZZO; HANDL, 2013).
6.3.2 Suporte à escrita
Os serviços OData possuem suporte à escrita. Eles disponibilizam operações para cria-
ção, atualização e deleção de algumas ou todas as entidades definidas na interface do serviço.
Para criar uma entidade em uma coleção, por exemplo, o cliente envia uma requisição HTTP
POST para a URL da coleção. O corpo dessa requisição precisa conter uma única e válida
representação da entidade. A requisição abaixo, na Listagem 30, cria uma pessoa a qual con-
tém uma coleção de propriedades, inclusive propriedades multivaloradas.
1 POST http://services.odata.org/V4/TripPinServiceRW/People
2 Content-Type: application/json
3 Accept: application/json
4
5 {
6 "@odata.type":"Microsoft.OData.SampleService.Models.TripPin.Person",
7 "UserName": "teresa",
8 "FirstName" : "Teresa",
9 "LastName" : "Gilbert",
10 "Gender" : "Female",
11 "Emails" : ["teresa@example.com", "teresa@contoso.com"],
12 "AddressInfo" : [
13 {
14 "Address" : "1 Suffolk Ln.",
15 "City" :
16 {
17 "CountryRegion" : "United States",
18 "Name" : "Boise",
19 "Region" : "ID"
20 }
21 }
22 ]
23 }
Listagem 30 Inserção de uma instância via HTTP POST.
A deleção por meio do serviço OData é executada via requisição HTTP DELETE, on-
de a URL deve informar o identificador da instância. A deleção, por exemplo, da instância
inserida na listagem acima seria:
DELETE http://services.odata.org/V4/TripPinServiceRW/People('teresa')
Os serviços OData devem suportar o comando HTTP PATCH e esse comando deve
ser utilizado como o principal meio de atualizar uma instância. Contudo, o comando HTTP
91
PUT também deve ser suportado, visto que a especificação OData é alinhada aos princípios
do estilo arquitetural REST. A requisição HTTP PUT é bastante semelhante ao HTTP POST,
pois no corpo da requisição deve haver uma única e válida representação de uma instância.
Por outro lado, na requisição HTTP PATCH o corpo da requisição contém apenas as proprie-
dades que se deseja alterar associadas a seus novos valores.
6.3.3 Suporte à verificação de integridade
As restrições de integridade no modelo EDM são semelhantes às restrições em um

banco de dados relacional. Como o EDM é uma extensão do modelo relacional ele utiliza a
suposição de mundo fechado. Assim, da mesma forma que uma coluna (ou colunas) de uma
tabela em um banco de dados pode fazer referência à chave primária de outra tabela, a propri-
edade (ou propriedades) de um tipo de instância pode referenciar o identificador de outro tipo
de instância.
6.3.4 Interface descritora de serviço
A interface OData é descrita por meio da especificação CSDL (Common Schema De-
finition Language) (PIZZO; HANDL; ZURMUEHL, 2014b). Essa especificação define uma
representação XML do modelo EDM. Um serviço OData é definido por um único documento
CSDL que pode ser acessado por meio de uma requisição HTTP GET para http://<endpoint
do serviço>/$metadata. Esse documento é chamado de documento de meta-dados e ele pode
referenciar outros documentos CSDL. O documento de meta-dados define as entidades expos-
tas pelo serviço e descreve suas relações. Esse documento também representa uma interface
abstrata, pois não há informações de binding que liguem a interface a um host em particular.
Por fim, o CSDL não relaciona explicitamente quais métodos HTTP são válidos para cada
entidade, assume-se que toda entidade é manipulável por qualquer método HTTP, além disso
o CSDL não utiliza ontologias para formalizar a semântica dos seus vocabulários.
6.4 Linked Data Services (LIDS)
Uma quantidade considerável de dados na Web está disponível via Web APIs que ex-
põem esses dados em formatos como JSON ou XML. A abordagem de serviços de dados in-
92
terligados — Linked Data Services (LIDS) (SPEISER; HARTH, 2010) — tem como objetivo
criar envoltórios em serviços Web provedores de dados pré-existentes, fornecendo assim uma
Web API que disponibiliza os dados na forma de dados interligados. Isso permite combinar
dados provenientes de diferentes APIs e fontes de dados, facilitando a integração entre servi-
ços provedores de dados.
A abordagem LIDS sempre apresenta seus dados de acordo com o modelo RDF. Os
dados de entrada no serviço podem vir em formatos como JSON ou XML, mas as saídas
sempre são em RDF.
A abordagem LIDS não tem suporte à escrita de dados. Ela tem como foco a consulta
a serviços de dados pré-existentes e a conversão dos dados retornados em uma representação
RDF. Não fazem parte de suas atribuições, portanto, a inserção e a modificação dos dados.
Por ser uma abordagem focada em leitura de dados, não há a necessidade de LIDS
possuir suporte à verificação de integridade de dados.
A interface LIDS descreve uma função e seus parâmetros de entrada e saída. Ela adota
a sintaxe Notation 3 (BERNERS-LEE; CONNOLLY, 2011), ou RDF/N3, como o formato de
descrição da interface de serviço. A Listagem 31 mostra um exemplo dessa interface. Esse
exemplo foi adaptado do artigo “Integrating Linked Data and Services with Linked Data Ser-
vices” (SPEISER; HARTH, 2011).
93
1 @prefix lids: <http://openlids.org/vocab#>

2
3 :GeowrapperNearby a lids:LIDS;
4 lids:lids_description [
5 lids:endpoint <http://example.com/geowrapper/findNearby>;
6 lids:service_entity “point”;
7 lids:input_bgp “?point a Point.
8 ?point geo:lat ?lat.
9 ?point geo:long ?long”;
10 lids:output_bgp “?point foaf:based_near ?feature”;
11 lids:required_vars “lat long”
12 ].
Listagem 31: Interface LIDS descrita em formato RDF/N3 (Notation 3).
A Listagem 31 descreve o serviço GeowrapperNearby (linha 3) que define a função

findNearby (linha 5) cujos parâmetros de entrada são a latitude, propriedade geo:lat, (linha 8)
e a longitude, propriedade geo:long, (linha 9) de um ponto geográfico Point (linha 7). Essa
função retorna o valor da propriedade foaf:based_near (linha 10) do ponto geográfico passado
como entrada.
6.5 Linked Data Platform (LDP)
O ponto focal da abordagem Linked Data Platform (SPEICHER; ARWE;

MALHOTRA, 2014) é promover uma série de melhores práticas para publicação de dados
interligados na Web que possam ser lidos e escritos via o protocolo HTTP.
A abordagem LDP se desenvolveu a partir o modelo RDF, assim, essa abordagem

descreve o uso do HTTP para acessar, atualizar, criar e deletar recursos de serviços que ex-
põem dados como dados interligados. O modelo RDF é o modelo nativo e único modelo su-
portado pelos serviços LDP.
A abordagem LDP alinha o modelo RDF com o estilo arquitetural REST. Portanto, o
suporte à escrita é garantido via os comandos HTTP POST e PUT, enquanto a remoção de
dados é garantida via o comando HTTP DELETE.
94
A abordagem LDP não faz extensões à linguagem OWL, nem à linguagem RDF, por-
tanto, nessa abordagem adota-se unicamente a suposição de mundo aberto, típica da Web se-
mântica. Assim não há suporte à verificação de integridade de dados nos moldes discutidos
neste trabalho (de suposição de mundo fechado localmente).
A especificação atual da abordagem LDP não define nada a respeito de uma interface
de serviço. Contudo, até a data de conclusão deste trabalho essa especificação ainda não era
uma recomendação de fato, mas estava no estágio de draft na W3C.
6.6 SPARQL 1.1 Protocol
A abordagem SPARQL 1.1 Protocol baseia-se em uma linguagem de consulta e mani-

pulação de dados. Ela descreve os meios para transmitir consultas e atualizações SPARQL
para um serviço SPARQL e retornar os resultados via HTTP para o cliente requisitor. Essa
abordagem foi desenvolvida pelo W3C SPARQL Working Group, como parte das atividades
de desenvolvimento da Web semântica.
A especificação SPARQL 1.1 Protocol utiliza o RDF como modelo de dados. Contu-
do, essa especificação possui três sintaxes de formato de dados. Essas sintaxes são definidas
em documentos de especificação próprios, enumerados a seguir:
 SPARQL XML Results Format (BECKETT; BROEKSTRA, 2013);

 SPARQL JSON Results Format (SEABORNE, 2013a);
 SPARQL CSV/TSV Results Format (SEABORNE, 2013b).
Tais especificações definem os formatos de retorno dos dados em uma consulta

SPARQL. Também é possível que uma consulta seja retornada diretamente em uma serializa-
ção do modelo RDF. A seleção de qual formato será utilizado vai depender basicamente da
95
forma de negociação de conteúdo (content negociation, descrito na RFC 2616) (FIELDING et

al., 1999) disponível no serviço SPARQL e do tipo de consulta executada, i.e., SELECT,
ASK, DESCRIBE ou CONSTRUCT.
A Figura 36 ilustra uma instância RDF. Essa instância representa o aluno “#Hermano”
e suas propriedades. Ela é descrita em RDF/XML na Listagem 32.
Figura 36: Instância do aluno "#Hermano" apresentada graficamente.
1 <rdf:RDF xmlns="http://www.unifor.br/serin/universidade.owl#"
2 xml:base="http://www.unifor.br/serin/universidade.owl"
5 <curso>Mestrado em Informática Aplicada</curso>
6 <nome>Hermano A. Lira</nome>
7 <CPF>82616973391</CPF>
8 <matricula>10001</matricula>
9 <anoIngresso>2011</anoIngresso>
10 <turma>13</turma>
11 </Aluno>
12 </rdf:RDF>
Listagem 32: Instância do aluno "#Hermano" em RDF/XML.
A obtenção da instância “#Hermano”, em um serviço SPARQL, pode ser feita por

meio da consulta SELECT * WHERE {<#Hermano> ?p ?o} e os retornos desse SE-
LECT nos formatos XML, JSON e CSV podem ser observados, respectivamente, na Listagem
33, Listagem 34 e Listagem 35.
2 <sparql xmlns="http://www.w3.org/2005/sparql-results#">
3 <head>
4 <variable name="p"/>
5 <variable name="o"/>
6 </head>
7 <results>
8 <result>
9 <binding name="p">
10 <uri>http://www.w3.org/1999/02/22-rdf-syntax-ns#type</uri>
11 </binding>
12 <binding name="o">
13
<uri>http://www.unifor.br/serin/universidade.owl#Aluno</uri>
14 </binding>
15 </result>
16 <result>
96
13 <uri>http://www.unifor.br/serin/universidade.owl#Aluno</uri>
14 </binding>
15 </result>
16 <result>
18 <uri>http://www.unifor.br/serin/universidade.owl#curso</uri>
19 </binding>
21 <literal>Mestrado em Informática Aplicada</literal>
22 </binding>
23 </result>
24 <result>
26 <uri>http://www.unifor.br/serin/universidade.owl#nome</uri>
27 </binding>
29 <literal>Hermano A. Lira</literal>
30 </binding>
31 </result>
32 <result>
34 <uri>http://www.unifor.br/serin/universidade.owl#CPF</uri>
35 </binding>
37 <literal>82616973391</literal>
38 </binding>
39 </result>
40 <result>
42 <uri>http://www.unifor.../universidade.owl#matricula</uri>
43 </binding>
46 </binding>
47 </result>
48 <result>
50 <uri>http://www.unifor.../universidade.owl#anoIngresso</uri>
51 </binding>
54 </binding>
55 </result>
56 <result>
58 <uri>http://www.unifor.br/serin/universidade.owl#turma</uri>
59 </binding>
62 </binding>
63 </result>
64 </results>
65 </sparql>
Listagem 33: Retorno XML da consulta SPARQL para a instância "#Hermano".

97
1 {
2 "head": {
3 "vars": ["p", "o"]
4 },
5 "results": {
6 "bindings": [
7 {
8 "p": {"type": "uri", "value": "#type"},
9 "o": {"type": "uri", "value": "#Aluno"}
10 },
11 {
12 "p": {"type": "uri", "value": "#curso"},
13 "o": {"type": "typed-literal",
14 "value": "Mestrado Informática Aplicada"}
15 },
16 {
17 "p": {"type": "uri", "value": "#nome"},
19 "value": "Hermano A. Lira"}
20 },
21 {
22 "p": {"type": "uri", "value": "#CPF"},
24 "value": "82616973391"}
25 },
26 {
27 "p": {"type": "uri", "value": "#matricula"},
28 "o": {"type": "typed-literal", "value": "10001"}
29 },
30 {
31 "p": {"type": "uri", "value": "#anoIngresso"},
33 },
34 {
35 "p": {"type": "uri", "value": "#turma"},
37 }
38 ]
39 }
40 }
Listagem 34: Retorno JSON da consulta SPARQL para a instância "#Hermano".
1 p, o
2 #type, http://www.unifor.br/serin/universidade.owl#Aluno
3 http://www.unifor.br/serin/universidade.owl#curso, Mestrado em Infor-
4 mática Aplicada
6 http://www.unifor.br/serin/universidade.owl#nome, Hermano A. Lira
7 http://www.unifor.br/serin/universidade.owl#CPF, 82616973391
8 http://www.unifor.br/serin/universidade.owl#matricula, 10001
9 http://www.unifor.br/serin/universidade.owl#anoIngresso, 2011
10 http://www.unifor.br/serin/universidade.owl#turma, 13
Listagem 35: Retorno CSV da consulta SPARQL para a instância "#Hermano".
Os exemplos apresentados nas três listagens acima são equivalentes, todos usam sinta-
xes distintas para expressar a mesma informação. Estruturalmente, todos os exemplos podem
ser representados de forma tabular, como na Tabela 5.
98
Tabela 5: Instância "#Hermano" representada em formato de tabela.
p o
http://www.w3.org/1999/02/22-rdf-syntax-ns#type http://www.unifor.br/serin/universidade.owl#Aluno
http://www.unifor.br/serin/universidade.owl#curso Mestrado em Informática Aplicada
http://www.unifor.br/serin/universidade.owl#nome Hermano A. Lira
http://www.unifor.br/serin/universidade.owl#CPF 82616973391
http://www.unifor.br/serin/universidade.owl#matricula 10001
http://www.unifor.br/serin/universidade.owl#anoIngresso 2011
http://www.unifor.br/serin/universidade.owl#turma 13
A especificação SPARQL 1.1 Protocol (FEIGENBAUM et al., 2013), em sua Seção

2.1.6 Success Responses, afirma que os formatos XML, JSON e CSV/TSV de resultados de
consultas SPARQL são utilizados para consultas executadas via SELECT ou ASK, enquanto
as consultas executadas via DESCRIBE ou CONSTRUCT retornam um grafo RDF serializa-
do na sintaxe RDF/XML.
Verificou-se que o resultado retornado por consultas do tipo DESCRIBE e CONS-

TRUCT para obtenção da instância “#Hermano” em um servidor Fuseki26 (uma implementa-
ção de referência da especificação SPARQL 1.1 Protocol) retorna os dados dessa instância de
maneira análoga à representação da Listagem 32. As consultas feitas foram:
 CONSTRUCT {<http://www.unifor.br/serin/universidade.owl#Hermano> ?p ?o}

WHERE {<http://www.unifor.br/serin/universidade.owl#Hermano> ?p ?o}
 DESCRIBE <http://www.unifor.br/serin/universidade.owl#Hermano>
O primeiro conjunto de documentos para especificação da linguagem SPARQL (ver-

são 1.0) não possuía suporte à escrita. Contudo, na versão atual (versão 1.1) essa limitação foi
resolvida. Dentre todos os documentos de especificações SPARQL, um em particular trata
exclusivamente de mecanismos para inserção, atualização e remoção de dados: a especifica-
ção SPARQL 1.1 Update (GEARON; PASSANT; POLLERES, 2013). Essa especificação
define uma extensão à linguagem SPARQL que incorpora os comandos INSERT e DELETE
26
http://jena.apache.org/documentation/serving_data/index.html
99
para prover inserção, atualização e remoção de dados. A operação de atualização não possui
um comando UPDATE formalmente definido. Para executar uma atualização de dados, utili-
za-se um comando combinado DELETE/INSERT.
As especificações SPARQL 1.1 Protocol e SPARQL 1.1 Update se integram para

permitir que os serviços SPARQL possam receber requisições de atualização de dados.
Não há mecanismo de verificação de integridade definido para o SPARQL Protocol.
Apenas recentemente os serviços SPARQL ganharam uma especificação para um des-

critor de serviço. A especificação SPARQL 1.1 Service Description (WILLIAMS, 2013) de-
fine um descritor de serviço aderente à especificação SPARQL 1.1 Protocol. A SPARQL 1.1
Service Description fornece tanto um método para descobrir serviços SPARQL, quanto um
vocabulário para descrevê-los. Por meio desse descritor, um cliente pode descobrir informa-
ções relevantes sobre a base de dados do serviço.
O descritor SPARQL (Service Description Document) é um documento RDF. Ele po-

de ser serializado tanto em RDF/XML quanto pode ser incorporado em uma página
(X)HTML por meio de RDFa (ADIDA et al., 2013). Para sua obtenção, basta que o cliente
faça uma requisição HTTP GET ao endpoint do serviço. Além disso, sua semântica é formali-
zada por meio do vocabulário http://www.w3.org/ns/sparql-service-description#. A
Listagem 36 apresenta um exemplo desse descritor.
1 <?xml version="1.0" encoding="utf-8"?>

2 <rdf:RDF
3 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4 xmlns:sd="http://www.w3.org/ns/sparql-service-description#"
5 xmlns:prof="http://www.w3.org/ns/owl-profile/"
6 xmlns:void="http://rdfs.org/ns/void#">
7 <sd:Service>
8 <sd:endpoint rdf:resource="http://www.example/sparql/"/>
9 <sd:supportedLanguage rdf:resource="sd&SPARQL11Query"/>
10 <sd:resultFormat rdf:resource="http://www.w3.org/ns/formats/RDF_XML"/>
11 <sd:resultFormat rdf:resource="http://www.w3.org/ns/formats/Turtle"/>
12 <sd:feature rdf:resource="sd&DereferencesURIs"/>
13 <sd:defaultEntailmentRegime rdf:resource="http://www.w3.org/ns/entailment/RDFS"/>
14 <sd:extensionFunction>
15 <sd:Function rdf:about="http://example.org/Distance"/>
16 </sd:extensionFunction>
17 <sd:defaultDataset>
18 <sd:Dataset>
19 <sd:defaultGraph>
20 <sd:Graph>
21 <void:triples>100</void:triples>
22 </sd:Graph>
23 </sd:defaultGraph>
24 <sd:namedGraph>
100
17 . <sd:defaultDataset>
18 <sd:Dataset>
19 <sd:defaultGraph>
20 <sd:Graph>
22 </sd:Graph>
23 </sd:defaultGraph>
24 <sd:namedGraph>
25 <sd:NamedGraph>
26 <sd:name rdf:resource="http://www.example/named-graph"/>
27 <sd:entailmentRegime
28 rdf:resource="http://www.w3.org/ns/entailment/OWL-RDF-Based"/>
29 <sd:supportedEntailmentProfile
30 rdf:resource="http://www.w3.org/ns/owl-profile/RL"/>
31 <sd:graph>
32 <sd:Graph>
34 </sd:Graph>
35 </sd:graph>
36 </sd:NamedGraph>
37 </sd:namedGraph>
38 ...
38 </sd:Dataset>
39 Listagem 36: Documento de descrição de serviço SPARQL.
</sd:defaultDataset>
40 </sd:Service>
41 </rdf:RDF>
A linha 8 da Listagem 36 especifica o endpoint do serviço. O descritor também infor-

ma, na linha 9, qual versão da linguagem SPARQL é suportada pelo serviço, quais os forma-
tos disponíveis para retorno de resultados (linhas 10 e 11), além de descrever diversos meta-
dados do serviço (linhas 17 a 37).
6.7 Comparação entre Serviços de Acesso a Dados
Nas seções anteriores, foram apresentadas em detalhes, as principais abordagens na

área de serviços de acesso a dados. Nesta seção, essas abordagens são comparadas a de servi-
ços de dados semânticos (SDS). Analisa-se as diferenças em relação ao suporte ao RDF, ao
suporte à escrita, ao suporte à verificação de integridade e a disposição de uma interface des-
critora de serviço. A Tabela 6 apresenta um resumo das diferenças e semelhanças analisadas.
Os valores Sim e Não, que ocorrem na tabela, referem-se à presença (Sim) e ausência (Não)
das características comparadas.
Tabela 6: Comparação entre trabalhos relacionados.
Característica OData LIDS LDP SPARQL SDS

Suporte ao modelo de dados RDF Não Sim Sim Sim Sim
Suporte à escrita de dados Sim Não Sim Sim Sim
Suporte à verificação de integridade Sim Não Não Não Sim
Possui interface descritora de serviço Sim Sim Não Sim Sim
101
A partir dessa análise são discutidos os benefícios da utilização de serviços SDS e es-
tabelecidos os cenários onde esses serviços promovem uma melhoria no acesso a dados inter-
ligados.
Dentre as abordagens de serviços de acesso a dados avaliadas neste trabalho, apenas a

abordagem OData não possui suporte ao modelo RDF. Ela atualmente é compatível apenas o
modelo EDM. Esse modelo representa os dados como entidades e relacionamentos e, diferen-
temente do RDF, não possibilita a construção de grafos de conhecimentos, nem permite a
descrição de conceitos por meio de ontologias. Essa limitação no modelo adotado pelo OData
dificulta sua utilização no contexto da Web de dados interligados.
As abordagens LIDS, LDP, SPARQL Protocol e SDS, por outro lado, possuem supor-
te ao modelo RDF. No entanto, algumas particularidades entre essas abordagens precisam ser
destacadas. Os serviços LDP, por exemplo, sempre retornam seus dados de acordo com mo-
delo RDF. Em contraste a isso, nos serviços SPARQL a adoção do RDF vai depender do tipo
de consulta executada. Consultas do tipo SELECT e ASK não retornam dados alinhados ao
modelo RDF. No caso do SELECT o retorno da consulta é devolvido em um formato tabular,
chamado SPARQL Result format, onde as colunas da tabela são as variáveis declaradas na
consulta executada (como pode ser visto na Tabela 5). Já a consultas do tipo ASK, sempre
retornam valores booleanos. Assim, esse tipo de consulta nunca retorna informações sobre as
possíveis soluções de uma consulta, apenas diz se existe solução ou não. Somente as consultas
do tipo DESCRIBE e CONSTRUCT retornam dados de acordo com o modelo RDF, e essas
duas consultas são semanticamente equivalentes a uma requisição HTTP GET na abordagem
SDS.
Apenas as abordagens LIDS e SDS permitem delimitar o domínio de conhecimento a

que pertencem seus dados. Nas duas abordagens os dados são visões de conceitos definidos
em suas interfaces. Por outro lado, os serviços SPARQL não delimitam o domínio dos seus
dados, permitindo, assim, a inserção de dados cujos conceitos não estejam definidos em sua
interface.
Dentre as abordagens aderentes ao modelo RDF, apenas a SDS define (Seção 3.3.2),
para seus dados, uma granularidade equivalente a de objetos (de acordo com o paradigma da
102
orientação a objeto). As outras abordagens se restringem a adotar a granularidade padrão do

modelo RDF, que é de representar a unidade de informação como uma tripla (sujeito — pre-
dicado — valor). Essa granularidade muito fina nem sempre é razoável para representar con-
ceitos do mundo real. Assim, a abordagem SDS define as características que um conjunto de
triplas precisa possuir para ser considerado equivalente a um objeto consistente. Essa defini-
ção é bastante útil, pois permite a visualização de conjuntos de triplas sempre agregadas como
um conjunto coeso e facilmente mapeado para os modelos de objeto ou relacional. Facilita
também a leitura das informações por um agente (humano ou de software), pois todas as tri-
plas estão sempre conectadas a um único contexto.
Dentre as abordagens analisadas, apenas a LIDS não possui suporte à escrita. Essa
abordagem diferentemente das outras apresentadas neste trabalho não possui uma base de
dados associada. Os serviços LIDS se propõem exclusivamente a encapsular serviços Web
pré-existentes que não possuam uma representação de dados em RDF. Essa abordagem, por-
tanto, concentra-se apenas em disponibilizar uma visão de serviços meramente sintáticos, co-
mo dados interligados. A adição da estrutura semântica do RDF possibilita uma navegação
facilitada e integrada entre fontes de dados.
Segundo (SPEISER; HARTH, 2011), a principal dificuldade na construção de um ser-

viço LIDS reside no acesso ao serviço nativo e no mapeamento de suas saídas para uma re-
presentação de dados interligados. Enquanto para alguns serviços é suficiente escrever um
conversor simples em JavaScript que transforme os dados de JSON para RDF/N3, em outros
serviços é necessária a escrita de procedimentos em Java ou de XSLTs que transformem os
dados de saída de XML para RDF/XML. O esforço é ainda maior para os serviços que ma-
peiam seus dados como páginas Web, pois isso muitas vezes requer uma sessão, a manipula-
ção de cookies e a análise de códigos HTML. Por toda essa complexidade no mapeamento
dos modelos de dados dos serviços nativos, a abordagem LIDS limita-se apenas a publicar
dados, não disponibilizando um mecanismo para a escrita dos mesmos.
Dentre as abordagens com suporte à escrita, a OData, a LDP e a SDS possuem uma
forte aderência ao estilo arquitetural REST. Isso significa que a inserção de uma nova infor-
mação por meio desses serviços se dá pela invocação do comando HTTP POST. De forma
análoga, a atualização acontece por meio do comando HTTP PUT e a deleção via comando
103
HTTP DELETE. A adoção dos princípios REST, por essas abordagens, tem a vantagem de
tornar esses serviços bastante alinhados com a arquitetura da Web. Isso permite aproximar a
Web de dados interligados da Web tradicional (de documentos).
Enquanto as abordagens SDS, OData e LDP utilizam a semântica já estabelecida dos

métodos HTTP para manipular dados interligados, nos serviços SPARQL qualquer operação
de atualização, inserção ou remoção se dá sempre por meio do método HTTP POST. Os mé-
todos HTTP PUT e HTTP DELETE não são utilizados. Essa falta de aderência dos serviços
SPARQL ao protocolo HTTP dificulta a utilização dessa abordagem por agentes de software,
pois prejudica a comunicação e integração de dados entre eles. A Tabela 7 mostra quais mé-
todos HTTP são utilizados para cada tipo de operação nas abordagens SDS e SPARQL.
Tabela 7: Diferenças entre SDS e SPARQL com relação às requisições HTTP.
Descrição SDS SPARQL 1.1 Protocol

Requisição para inserção de dados HTTP POST HTTP POST
Requisição para atualização de dados HTTP PUT HTTP POST
Requisição para remoção de dados HTTP DELETE HTTP POST
Poder verificar a adequação e a integridade dos dados é fundamental para diversos ce-
nários do mundo real. Assim, muitos modelos de representação de dados possuem mecanis-
mos com essa finalidade. No paradigma da orientação a objetos, por exemplo, é possível ga-
rantir a integridade de um objeto por meio do construtor de sua classe. O construtor impõe
quais atributos do objeto precisam necessariamente estar preenchidos. De maneira semelhan-
te, as restrições de integridade definidas no esquema de um banco de dados relacional garan-
tem que a inserção de uma tupla só será permitida caso todas as colunas necessárias à consis-
tência dessa tupla estejam preenchidas e satisfazendo as regras definidas no esquema. Em
contraste a isso, o modelo RDF não possui nenhum mecanismo para garantir que uma deter-
minada propriedade seja obrigatoriamente (e explicitamente) associada a uma instância RDF.
Sobre essa perspectiva não há como garantir a consistência ou coerência de um conjunto de
triplas RDF dentro de um determinado domínio de conhecimento.
A abordagem SDS permite validar a consistência dos dados inseridos em uma base por
meio de anotações dispostas na interface SERIN que verificam a integridade de dados segun-
104
do a semântica do mundo fechado localmente (Seção 4.3). Dentre as abordagens analisadas

neste trabalho, apenas as abordagens OData e SDS possuem mecanismos de verificação de
integridade com semântica alinhada à suposição de mundo fechado. Contudo, a abordagem
OData não trabalha com o modelo RDF. Assim, a abordagem SDS possui a importante con-
tribuição de ser a única, dentre as abordagens analisadas, a estender a semântica do modelo
RDF para permitir a verificação de integridade nos moldes da suposição de mundo fechado
localmente.
Enquanto a abordagem SDS estende o modelo RDF para tratar a suposição de mundo
fechado localmente, as abordagens LDP e SPARQL Protocol tratam os dados interligados
exclusivamente de acordo com a suposição de mundo aberto. Essa diferença com relação à
forma como os dados são interpretados, faz consigo uma série de implicações.
Tanto a abordagem LDP quanto a SPARQL permitem que qualquer tripla seja inserida
em suas bases independentemente de qual seja o domínio de conhecimento ao qual essa tripla
pertença. A suposição de mundo aberto não permite estabelecer o escopo de quais dados são
suscetíveis de serem inseridos na base e quais não são. Em razão disso, não há como se esta-
belecer um esquema para a representação do domínio de conhecimento nesses serviços.
A ausência de um esquema para os serviços LDP e SPARQL torna difícil a manuten-

ção da integridade dos seus dados, pois não há mecanismo formal definido nessas abordagens
que permita controlar que tipos de dados são inseridos na base do host. Assim, é difícil garan-
tir que apenas dados de um domínio específico sejam inseridos.
Suponha, por exemplo, um host de uma universidade onde sua base é disponibilizada
por meio de um serviço SPARQL. Suponha também que a intenção original de quem criou a
base é que ela mantenha dados relacionados ao cadastro de alunos, suas disciplinas matricula-
das, seu histórico escolar, etc. Na especificação SPARQL 1.1 Protocol nada impediria que
uma aplicação cliente inserisse dados não relacionados com esse domínio de conhecimento.
Um professor fã de futebol, por exemplo, poderia incluir na base o resultado da última rodada
de jogos do campeonato brasileiro — o que evidentemente não estava na intenção original de
quem criou a base — e o servidor SPARQL da universidade iria aceitar esses dados por não
possuir um mecanismo capaz de verificar a adequação dos dados a finalidade pretendida para
a base. Isso acontece por que a intenção de qual domínio de conhecimento deve ser mantido
na base foi definida informalmente. Não existe um esquema em SPARQL que indique quais
dados podem ser inseridos e quais não podem na base em questão. É difícil imaginar na práti-
105
ca uma base de dados com permissão de escrita onde qualquer informação aleatória possa ser
inserida sem nenhum tipo de controle. Uma situação dessas é potencialmente perigosa visto
que não há como garantir a consistência nem a coerência dos dados dentro de um contexto.
Qualquer tipo de controle que tente restringir a inserção de dados em um serviço

SPARQL ou LDP, sobre qualquer aspecto, deve ser feito informalmente, pois não existe ne-
nhuma especificação que proponha a formalização desse tipo de necessidade. Portanto, não é
possível garantir que serviços idealizados para um propósito específico mantenham apenas
dados relacionados a esse domínio especifico. Nem é possível garantir que tais dados sejam
tão completos e consistentes quanto se deseje. Essa limitação com frequência inibe provedo-
res de dados de disponibilizarem seus serviços com permissão de escrita. Limitando-os a pro-
ver apenas consultas a dados.
A interface CSDL do OData e a interface SERIN do SDS são semelhantes em vários

aspectos, pois ambas atuam com um esquema para as bases de dados de seus serviços, ambas
possuem mecanismos para verificação de integridade, ambas respondem às requisições HTTP
de acordo com os princípios REST e ambas adotam uma convenção de endereçamento pare-
cida, para construção de suas URLs. Contudo, a interface SERIN é uma ontologia escrita na
linguagem OWL, enquanto a interface do OData é uma representação do modelo EDM escrita
em XML. Assim, a falta de suporte ao modelo RDF é possivelmente maior limitação dos ser-
viços OData no que se refere a sua utilização no contexto da Web de dados interligados.
A interface da abordagem LIDS, diferentemente das duas anteriores, possui uma ênfa-
se maior na descrição de chamadas de funções. A invocação das funções definidas nessa inter-
face se dá por meio de requisições HTTP GET. Essa abordagem não utiliza os comandos
HTTP POST, PUT ou DELETE, pois não há suporte à escrita de dados. Além disso, ela não
adere aos princípios REST, uma vez que a semântica de uma requisição HTTP GET é defini-
da pela função que está sendo invocada. É importante destacar que todos os dados de retorno
nos serviços LIDS possuem suas classes e propriedades definidas na interface. Assim como
na abordagem SDS, a interface LIDS informa os tipos de dados presentes na base e não é pos-
sível recuperar dados cujas classes e propriedades não estejam definidas nela. Diferentemente
da interface SERIN, a interface LIDS não é abstrata, pois ao definir uma função, a interface
expõe a URL onde o serviço está localizado. Isso impossibilita que a interface seja utilizada
106
por mais de um host. Por exemplo, para a função findNearby a interface expõe o endpoint
http://example.com/geowrapper/findNearby, onde a função pode ser invoca-
da.
A abordagem SPARQL ganhou recentemente uma nova especificação, a SPARQL 1.1

Service Description (WILLIAMS, 2013). O principal objetivo dessa especificação é prover
um documento RDF como um descritor de serviço que permita que agentes de software pos-
sam descobrir novos serviços e avaliar se os dados mantidos nesses serviços são relevantes
aos seus interesses. O descritor também informa aos agentes qual a linguagem de consulta
válida para as requisições ao serviço e qual o formato de retorno dos dados, entre outras coi-
sas. Nesse sentido, o descritor atua como uma interface, pois informa aos clientes que tipos de
informações o serviço oferece e como essas informações podem ser obtidas. Por esse motivo,
neste trabalho a especificação SPARQL 1.1 Service Description será tratada como a interface
dos serviços SPARQL. Contudo, é importante frisar que esse descritor não é obrigatório para
o funcionamento e utilização dos serviços SPARQL.
A interface SPARQL (quando houver) é construída especificamente para um host e

não pode ser compartilhada, como acontece com a interface SERIN. Ao contrário do SDS,
onde cada entidade, propriedade e valor possuem suas próprias URLs, nos serviços SPARQL
o acesso e manipulação a todos os dados se dá através de uma única URL, o endpoint, por
onde as consultas SPARQL são submetidas. As URIs associadas aos dados de um serviço
SPARQL são utilizadas para identificação de recursos, enquanto no SDS essas URIs são utili-
zadas tanto para identificação, quanto para localização de recursos. Por esse motivo, as URIs
dos serviços SDS são ditas desreferenciáveis, enquanto nos serviços SPARQL não há essa
garantia.
A exposição de meta-dados na interface (ou descritor) SPARQL é auxiliada pelo Vo-

cabulary of Interlinked Datasets (VoID) (ALEXANDER et al., 2011). VoID é um vocabulá-
rio próprio para expressar os meta-dados de bases RDF. Ele possibilita, entre outras coisas,
descrever na interface SPARQL, os conceitos (classes e propriedades) dos dados mantidos na
base do host. Todavia, é importante enfatizar que a utilização desse vocabulário pela interface
visa apenas auxiliar agentes de software a descobrirem que tipos de dados são mantidos por
determinados serviços SPARQL. Esse vocabulário não é obrigatório e, portanto, não há ga-
rantias de que sempre existam essas descrições de conceitos na interface. Essa não obrigatori-
edade contribui para que nem o vocabulário VoID, nem a interface SPARQL propriamente
107
dita possuam mecanismos de verificação de integridade que validem os dados a serem persis-
tidos na base. Assim, qualquer tripla pode ser persistida em um serviço SPARQL, mesmo que
tal tripla esteja associada a conceitos inexistentes na interface.
A interface SERIN permite separar claramente a informação de um host em dois con-

juntos disjuntos. O conjunto dos dados (recursos, instâncias) e o conjunto dos conceitos (clas-
ses, propriedades). A partir da definição clara das fronteiras entre esses dois conjuntos é pos-
sível estabelecer uma suposição mais adequada para interpretar os dados em contextos onde é
importante assegurar a integridade dos dados. A suposição de mundo fechado localmente tem
essa finalidade na abordagem SDS, enquanto nos serviços SPARQL, a suposição de mundo
aberto não permite separar claramente a ontologia dos dados descritos por ela. Assim, dados e
conceitos se misturam dentro da base de dados do host SPARQL. Não existe uma divisão
clara entre eles, o serviço SPARQL não impõe nenhum tratamento diferenciado entre dados e
conceitos. É possível, inclusive, executar comandos DELETE e remover conceitos que des-
crevem os dados mantidos na base. Isso não acontece nos serviços SDS, uma vez que os con-
ceitos estão definidos na interface SERIN e essa interface não pode ser alterada por nenhuma
requisição HTTP.
Por último, mas não menos importante, dentre as abordagens analisadas, apenas a
abordagem LDP não possui uma interface descritora de serviço. Contudo, essa abordagem é
também a mais recente. Até a data de conclusão deste trabalho ela ainda era uma especifica-
ção rascunho (draft) sendo trabalhada pelo W3C. Portanto, nada impede que no futuro especi-
fiquem uma interface para ela.
6.8 Sumário
Este capítulo apresentou os principais trabalhos na área de serviços de acesso a dados.

Mostraram-se suas vantagens e limitações. Em seguida, apresentou-se uma comparação entre
esses serviços e a abordagem SDS.
No próximo capítulo, serão apresentadas as conclusões deste trabalho, suas contribui-

ções e sugestões de trabalhos futuros.
Capítulo 7
7
Conclusão
Este capítulo apresenta as conclusões deste trabalho, incluindo suas principais con-
tribuições e propostas para trabalhos futuros.
7.1 Conclusões
Neste trabalho apresentou-se o serviço de dados semânticos (SDS). Tais serviços utili-
zam as interfaces SERIN para descrever quais tipos de dados estão mantidos na base de dados
do host. Essa interface é uma ontologia OWL que descreve as classes, as propriedades e as
relações que existem entre os dados. A interface SERIN também possui anotações que disci-
plinam quais métodos HTTP são utilizados para acessar e manipular os dados.
Estendeu-se, neste trabalho, o conjunto de anotações da interface SERIN. Foram defi-

nidas seis novas anotações (NotNull, Unique, Id, ForeignURI, Embedded e Internal) voltadas
para a garantia de integridade dos dados. Esse novo conjunto de anotações provê, para a abor-
dagem SDS, um mecanismo formal de verificação de integridade de dados baseado na suposi-
ção de mundo fechado localmente. Essa suposição não é considerada nos outros trabalhos de
serviços de acesso a dados interligados e ela permite definir regras especificas nos serviços
SDS que indicam quais dados devem ser explicitamente enviados em uma requisição HTTP
de escrita de dados. Com a adoção da suposição de mundo fechado localmente, a abordagem
SDS possibilita a utilização de dados interligados em cenários onde é importante a noção de
completude de dados na base do host.
Definiu-se também neste trabalho, uma arquitetura de software para suportar os servi-
ços SDS. Essa arquitetura é formada por três componentes: o processador de requisições, o
verificador de integridade e o de persistência. Assim, o primeiro componente se responsabili-
za por capturar as requisições HTTP; o segundo por analisar o conteúdo do corpo dessa requi-
sição (com relação a validade ou não dos dados) e o terceiro por prover uma camada de iso-
109
lamento que permite uma comunicação transparente entre o serviço SDS e a base de dados do
host.
Por fim, fez-se um estudo comparativo do SDS com outras abordagens de serviços de
acesso a dados. Na comparação o SDS mostrou-se vantajoso em relação ao OData por possi-
bilitar a manipulação de dados interligados, enquanto o OData limita-se a dados em XML ou
JSON. Com relação à abordagem LIDS, o SDS é vantajoso por permitir a inserção de dados,
enquanto o LIDS limita-se apenas em oferecer a opção de consulta. O LDP, embora bastante
semelhante ao SDS, tem como principal limitação a falta de uma interface que auxilie na des-
crição dos dados mantidos no host. Por último, o serviço SPARQL não possui mecanismo de
verificação de integridade de dados que permitam manipular seus dados oferecendo garantias
de consistência de acordo com a suposição de mundo fechado localmente. Isso inibe o desen-
volvimento de serviços SPARQL com suporte a escrita e voltados para o armazenamento de
dados de um domínio especifico.
7.2 Considerações Finais
Como resultados deste trabalho, espera-se que os serviços SDS facilitem a integração
de dados entre os hosts que aderirem à mesma interface semântica. Espera-se também que o
processo de descoberta, análise, comparação, seleção e utilização dos dados sejam facilitados,
uma vez que os serviços SDS vão publicar interfaces SERIN descrevendo que tipos de dados
eles oferecem. Espera-se que os serviços SDS ajudem a promover as tecnologias da Web se-
mântica, por meio da utilização dos padrões recomendados pelo W3C (i.e. RDF, OWL). Es-
pera-se que os serviços SDS forneçam uma solução para acesso e manipulação de dados que
disponibilize uma camada de abstração que esconda a complexidade do acesso às fontes de
dados subjacentes e por último, espera-se promover o uso de ontologias OWL como interfa-
ces de serviço de dados.
7.3 Limitações de Escopo e Trabalhos Futuros
Os serviços de dados semânticos (SDS) possuem algumas limitações que podem ser
abordadas e evoluídas em trabalhos futuros. Neste trabalho não se explorou a construção de
métodos e funções para serem invocadas pelo o serviço, apenas os métodos CRUD (create,
110
retrieve, update e delete) são suportados. Em trabalhos futuros é possível adicionar o suporte
a métodos com parâmetros de entrada e saída mais elaborados.
Este trabalho também não produziu uma solução específica para o controle de acesso e
autenticação de dados interligados. É certo que em muitas aplicações do mundo real é neces-
sário proteger os dados para que não sejam acessados ou modificados por qualquer um. As-
sim, os aspectos relacionados à segurança são tratados em nível do framework RESTEasy por
meio de especificações apropriadas, como por exemplo a OAuth. Contudo, há a possibilidade
de se estudar com mais profundidade e se evoluir esse mecanismo de controle de acesso em
trabalhos futuros.
Embora o próprio documento de especificação da URI permita a construção de query

strings na composição de uma URI, isso não foi explorado neste trabalho. Um possível traba-
lho futuro que pode explorar a utilização de query strings é o relacionado à passagem de pa-
râmetros para filtrar, paginar, selecionar ou ordenar (entre outras coisas) os dados do serviço
SDS com mais precisão.
Por último, os serviços SDS são alinhados ao estilo arquitetural REST e, portanto, uti-
lizam apenas os verbos do protocolo HTTP, e adotam rigorosamente a semântica definida no
próprio documento de especificação do protocolo. Portanto, o SDS não oferece suporte ao
verbo HTTP PATCH. Esse verbo (ou método) não é definido na documentação do protocolo
HTTP, mas em um documento a parte. Contudo, esse verbo oferece uma semântica mais fle-
xível para operações de atualização de dados e seu uso pode ser explorado em mais profundi-
da em trabalhos futuros de evolução do SDS.
Referências Bibliográficas
ADIDA, B. et al. RDFa Core 1.1 - Second Edition. Disponível em:

<http://www.w3.org/TR/rdfa-core/>. Acesso em: 18 fev. 2014.
ALEXANDER, K. et al. Describing Linked Datasets with the VoID Vocabulary.

Disponível em: <http://www.w3.org/TR/void/>. Acesso em: 16 ago. 2014.
AUER, S. et al. Use Cases and Requirements for Mapping Relational Databases to RDF.
Disponível em: <http://www.w3.org/TR/rdb2rdf-ucr/>. Acesso em: 18 fev. 2014.
BAADER, F. et al. (EDS.). The Description Logic Handbook: Theory, Implementation,

and Applications. New York, NY, USA: Cambridge University Press, 2003.
BECHHOFER, S. et al. OWL Web Ontology Language Reference. Disponível em:

<http://www.w3.org/TR/owl-ref/>. Acesso em: 18 fev. 2014.
BECKETT, D. RDF/XML Syntax Specification. Disponível em:

<http://www.w3.org/TR/rdf-syntax-grammar/>. Acesso em: 18 fev. 2014.
BECKETT, D. et al. RDF 1.1 Turtle - Terse RDF Triple Language. Disponível em:
<http://www.w3.org/TR/turtle/>. Acesso em: 18 fev. 2014.
BECKETT, D.; BROEKSTRA, J. SPARQL Query Results XML Format (Second

Edition). Disponível em: <http://www.w3.org/TR/rdf-sparql-XMLres/>. Acesso em: 10 maio.
2014.
BERNERS-LEE, T. Weaving the Web: The Original Design and Ultimate Destiny of the
World Wide Web by Its Inventor. [s.l.] Harper San Francisco, 1999. p. 226
BERNERS-LEE, T. Linked Data - Design Issues. Disponível em:

<http://www.w3.org/DesignIssues/LinkedData.html>. Acesso em: 1 mar. 2014.
BERNERS-LEE, T. et al. Realising A Read-Write Web of Data. [s.l: s.n.].
BERNERS-LEE, T.; CONNOLLY, D. Notation3 (N3): A readable RDF syntax. Disponível

em: <http://www.w3.org/TeamSubmission/n3/>. Acesso em: 10 nov. 2014.
BERNERS-LEE, T.; FIELDING, R.; MASINTER, L. RFC 3986, Uniform Resource

Identifier (URI): Generic Syntax. Disponível em: <http://www.ietf.org/rfc/rfc3986.txt>.
BERNERS-LEE, T.; HENDLER, J.; LASSILA, O. The Semantic Web. Scientific American,
v. 284, n. 5, p. 34 – 43, maio 2001.
112
BIZER, C.; HEATH, T.; BERNERS-LEE, T. Linked Data - The Story So Far. International
Journal on Semantic Web and Information Systems (IJSWIS), v. 5, n. 3, p. 1–22, mar.
2009.
BRAY, T. et al. Extensible Markup Language (XML) 1.0 (Fifth Edition). [s.l.] World
Wide Web Consortium, 2008.
CHAVES, L. M. et al. Semantic Interfaces Discovery Server. Proceedings of the 24th

International Conference on Software Engineering & Knowledge Engineering
(SEKE’2012), p. 80–87, 2012.
CHEN, P. P.-S. The Entity-relationship Model - Toward a Unified View of Data. ACM
Trans. Database Syst., v. 1, n. 1, p. 9–36, 1976.
CLARK, K. L. Negation as Failure (H. Gallaire, J. Minker, Eds.)Logic and Data Bases.
Anais...New York: Plenum Press, 1978
COPPENS, S. et al. A truly {Read-Write Web} for machines as the next-generation

{Web}?Proceedings of the SW2022 workshop: What will the Semantic Web look like
10~years from now? Anais...2012Disponível em:
<http://stko.geog.ucsb.edu/sw2022/sw2022_paper3.pdf>
DOHERTY, P.; LUKASZEWICZ, W.; SZALAS, A. Efficient reasoning using the local
closed-world assumptionIN PROC. 9TH AIMSA, LNCS 2407. Anais...2000
ETZIONI, O.; GOLDEN, K.; WELD, D. S. Sound and Efficient Closed-world Reasoning for
Planning. Artif. Intell., v. 89, n. 1-2, p. 113–148, 1997.
FANG, M. Maintaining Integrity Constraints in Semantic Web. [s.l.] Georgia State

University, 2013.
FEIGENBAUM, L. et al. SPARQL 1.1 Protocol. Disponível em:

<http://www.w3.org/TR/sparql11-protocol/>. Acesso em: 18 fev. 2014.
FENSEL, D. Ontologies: A Silver Bullet for Knowledge Management and Electronic

Commerce. 2. ed. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2003.
FIELDING, R. T. et al. Hypertext Transfer Protocol -- HTTP/1.1. [s.l: s.n.]. Disponível

em: <http://www.ietf.org/rfc/rfc2616.txt>. Acesso em: 25 jul. 2013.
FIELDING, R. T. Architectural styles and the design of network-based software

architectures. [s.l.] University of California, Irvine, 2000.
GARROTE, A.; GARCÍA, M. N. M. RESTful writable APIs for the web of Linked Data
using relational storage solutionsIn WWW2011 Workshop: Linked Data on the Web
(LDOW2011. Anais...2011
GEARON, P.; PASSANT, A.; POLLERES, A. SPARQL 1.1 Update. Disponível em:
<http://www.w3.org/TR/sparql11-update/>. Acesso em: 18 fev. 2014.
113
GRUBER, T. R. A translation approach to portable ontology specifications. KNOWLEDGE

ACQUISITION, v. 5, n. 2, p. 199–220, 1993.
HANDL, R.; PIZZO, M.; BIAMONTE, M. OData JSON Format Version 4.0. Disponível
em: <http://docs.oasis-open.org/odata/odata-json-format/v4.0/odata-json-format-v4.0.html>.
Acesso em: 15 mar. 2014.
HARRIS, S.; SEABORNE, A. SPARQL 1.1 Query Language. Disponível em:

<http://www.w3.org/TR/sparql11-query/>. Acesso em: 18 fev. 2014.
HEATH, T.; BIZER, C. Linked Data: Evolving the Web into a Global Data Space. [s.l.]
Morgan {&} Claypool Publishers, 2011.
HITZLER, P. et al. OWL 2 Web Ontology Language: Primer. Disponível em:

<http://www.w3.org/TR/owl2-primer/>. Acesso em: 18 fev. 2014.
HOLBROOK, S. et al. Submission Request to W3C: Linked Data Basic Profile 1.0.
Disponível em: <http://www.w3.org/Submission/2012/02/>. Acesso em: 19 mar. 2014.
HUSTADT, U. Do We Need the Closed-World Assumption in Knowledge

Representation?KRDB. Anais...1994
JACOBS, I.; WALSH, N. Architecture of the World Wide Web, Volume One. Disponível
em: <http://www.w3.org/TR/webarch/>. Acesso em: 18 fev. 2014.
KJERNSMO, K. The necessity of hypermedia RDF and an approach to achieve it.

Proceedings of the First Linked APIs workshop at the Ninth Extended Semantic Web
Conference, 2012.
KLYNE, G.; CARROLL, J. J. Resource Description Framework (RDF): Concepts and

Abstract Syntax. Disponível em: <http://www.w3.org/TR/rdf-concepts/>. Acesso em: 18
fev. 2014.
KNORR, M.; ALFERES, J. J.; HITZLER, P. Local Closed World Reasoning with
Description Logics Under the Well-founded Semantics. Artif. Intell., v. 175, n. 9-10, p.
1528–1554, 2011.
KRISNADHI, A.; SENGUPTA, K.; HITZLER, P. Local Closed World Semantics : Keep it
simple , stupid! Proceedings of the 24th International Workshop on Description Logics
(DL), 2011.
LANTHALER, M.; GUTL, C. Aligning Web Services with the Semantic Web to Create a
Global Read-Write Graph of DataProceedings of the 2011 IEEE Ninth European
Conference on Web Services. Anais...: ECOWS ’11.Washington, DC, USA: IEEE Computer
Society, 2011aDisponível em: <http://dx.doi.org/10.1109/ECOWS.2011.17>
LANTHALER, M.; GUTL, C. A semantic description language for RESTful Data

Services to combat SemaphobiaDigital Ecosystems and Technologies Conference (DEST),
2011 Proceedings of the 5th IEEE International Conference on. Anais...2011b
114
LANTHALER, M.; GÜTL, C. On Using JSON-LD to Create Evolvable RESTful

ServicesProceedings of the Third International Workshop on RESTful Design. Anais...: WS-
REST ’12.New York, NY, USA: ACM, 2012Disponível em:
<http://doi.acm.org/10.1145/2307819.2307827>
MALESHKOVA, M.; PEDRINACI, C.; DOMINGUE, J. Investigating Web APIs on the

World Wide WebProceedings of the 2010 Eighth IEEE European Conference on Web
Services. Anais...: ECOWS ’10.Washington, DC, USA: IEEE Computer Society,
2010Disponível em: <http://dx.doi.org/10.1109/ECOWS.2010.9>
MANOLA, F.; MILLER, E. RDF Primer. Disponível em: <http://www.w3.org/TR/rdf-

primer/>. Acesso em: 18 fev. 2014.
MOTIK, B.; HORROCKS, I.; SATTLER, U. Bridging the gap between OWL and relational
databases. Proceedings of the 16th international conference on World Wide Web
(WWW’07), WWW ’07. p. 807–816, 2007.
MUNIZ, B. D. A. et al. SERIN - SEMANTIC RESTFUL INTERFACES. Proceedings of the

IADIS International Conference on WWW/Internet, p. 463–467, 2011.
MUNIZ, B. DE A. et al. SERIN - AN APROACH TO SPECIFY SEMANTIC ABSTRACT

INTERFACES IN THE CONTEXT OF RESTFUL WEB SERVICES. Proceedings of the
IADIS International Conference on WWW/Internet, p. 187–194, 2013.
NALLY, M. et al. Linked Data Basic Profile 1.0. Disponível em:

<http://www.w3.org/Submission/ldbp/>. Acesso em: 19 mar. 2014.
NETO, J. C. C. Active OWL - Uma arquitetura para integrar Serviços Web e Ontologias.
[s.l.] UNIVERSIDADE DE FORTALEZA, 2007.
OGBUJI, C. SPARQL 1.1 Graph Store HTTP Protocol. Disponível em:

<http://www.w3.org/TR/sparql11-http-rdf-update/>. Acesso em: 18 fev. 2014.
PAGE, K. R.; DE ROURE, D. C.; MARTINEZ, K. REST and Linked Data: A Match
Made for Domain Driven Development?Proceedings of the Second International Workshop
on RESTful Design. Anais...: WS-REST ’11.New York, NY, USA: ACM, 2011Disponível
em: <http://doi.acm.org/10.1145/1967428.1967435>
PIZZO, M.; HANDL, R.; ZURMUEHL, M. OData Version 4.0 Part 1: Protocol. Disponível
em: <http://docs.oasis-open.org/odata/odata/v4.0/os/part1-protocol/odata-v4.0-os-part1-
protocol.html>. Acesso em: 15 mar. 2014a.
PIZZO, M.; HANDL, R.; ZURMUEHL, M. OData Version 4.0 Part 3: Common Schema
Definition Language (CSDL). Disponível em: <http://docs.oasis-
open.org/odata/odata/v4.0/os/part3-csdl/odata-v4.0-os-part3-csdl.html>. Acesso em: 15 mar.
2014b.
REITER, R. On Closed World Data Bases. In: GALLAIRE, H.; MINKER, J. (Eds.). . Logic
and Data Bases. New York: Plenum Press, 1978. p. 119–140.
115
RICHARDSON, L.; RUBY, S. RESTful web services. First ed. Sebastopol,CA: O’Reilly,
2007.
RUSSELL, S. J.; NORVIG, P. Artificial Intelligence: A Modern Approach. 2. ed. New

Jersey: Pearson Education, 2003.
SEABORNE, A. SPARQL 1.1 Query Results JSON Format. Disponível em:

<http://www.w3.org/TR/sparql11-results-json/>. Acesso em: 10 maio. 2014a.
SEABORNE, A. SPARQL 1.1 Query Results CSV and TSV Formats. Disponível em:
<http://www.w3.org/TR/sparql11-results-csv-tsv/>. Acesso em: 10 maio. 2014b.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Database System Concepts. 5. ed.

[s.l.] McGraw-Hill Science/Engineering/Math, 2005.
SIRIN, E.; TAO, J. Towards Integrity Constraints in OWLProceedings of the 5th

International Workshop on OWL: Experiences and Directions (OWLED). Anais...Chantilly,
VA, United States: CEUR-WS.org, 2009
Sistema Nota Fiscal Eletrônica. . Brasil: [s.n.]. Disponível em:

<http://www.nfe.fazenda.gov.br>.
SMITH, M.; WELTY, C.; MCGUINNESS, D. L. OWL Web Ontology Language Guide.
Disponível em: <http://www.w3.org/TR/owl-guide/>. Acesso em: 18 fev. 2014.
SPEICHER, S.; ARWE, J.; MALHOTRA, A. Linked Data Platform 1.0. Disponível em:
<http://www.w3.org/TR/ldp/>. Acesso em: 19 mar. 2014.
SPEISER, S.; HARTH, A. Taking the LIDS off data silosProceedings of the 6th
International Conference on Semantic Systems. Anais...: I-SEMANTICS ’10.New York, NY,
USA: ACM, 2010Disponível em: <http://doi.acm.org/10.1145/1839707.1839761>
SPEISER, S.; HARTH, A. Integrating Linked Data and Services with Linked Data
ServicesProceedings of the 8th Extended Semantic Web Conference on The Semantic Web:
Research and Applications - Volume Part I. Anais...: ESWC’11.Berlin, Heidelberg: Springer-
Verlag, 2011Disponível em: <http://dl.acm.org/citation.cfm?id=2008892.2008907>
SPORNY, M. et al. JSON-LD 1.0: A JSON-based Serialization for Linked Data.

Disponível em: <http://www.w3.org/TR/json-ld/>. Acesso em: 18 fev. 2014.
TAO, J. et al. Integrity Constraints in OWL (M. Fox, D. Poole, Eds.)Proceedings of the
Twenty-Fourth AAAI Conference on Artificial Intelligence (AAAI ). Anais...Atlanta,
Georgia, USA: AAAI Press, 2010a
TAO, J. et al. Extending OWL with Integrity Constraints (V. Haarslev, D. Toman, G. E.
Weddell, Eds.)Proceedings of the 23rd International Workshop on Description Logics (DL).
Anais...Waterloo, Ontario, Canada: CEUR-WS.org, 2010b
VERBORGH, R. et al. Functional Descriptions As the Bridge Between Hypermedia APIs

and the Semantic WebProceedings of the Third International Workshop on RESTful Design.
116
Anais...: WS-REST ’12.New York, NY, USA: ACM, 2012Disponível em:

<http://doi.acm.org/10.1145/2307819.2307828>
WILDE, E.; HAUSENBLAS, M. RESTful SPARQL? You name it!: aligning SPARQL
with REST and resource orientationNew York, {NY}, {USA}: ACM, 2009
WILLIAMS, G. T. SPARQL 1.1 Service Description. Disponível em:

<http://www.w3.org/TR/sparql11-service-description/>. Acesso em: 18 fev. 2014.
ZURMUEHL, M.; PIZZO, M.; HANDL, R. OData Atom Format Version 4.0. Disponível
em: <http://docs.oasis-open.org/odata/odata-atom-format/v4.0/odata-atom-format-v4.0.html>.
Acesso em: 15 mar. 2014.
117
Publicações
A seguir é apresentada a lista de publicações originadas a partir deste trabalho:
 LIRA, H. A. et al. Semantic data services: An approach to access and manipulate Linked
Data. In: Computing Conference (CLEI), 2014 XL Latin American. Anais... 2014. p. 717-
730.
 LIRA, H. A.; FARIAS, P. P. M. Semantic Data Services: Uma abordagem para leitura e
atualização de dados semânticos. In: XIX Simpósio Brasileiro de Sistemas Multimídia e
Web. Anais... Salvador, 2013. p. 33-36.
 MUNIZ, B. A.; LIRA, H. A. et al. SERIN: An Aproach to Specify Semantic Abstract In-
terfaces in the Context of RESTFul Web Services. In: Proceedings of the IADIS Interna-
tional Conference on WWW/Internet. Anais... Fort Worth, USA: IADIS Press, 2013

Dissertacao

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Dissertacao

Enviado por

Direitos autorais:

Formatos disponíveis

FUNDAÇÃO EDSON QUEIROZ

UNIVERSIDADE DE FORTALEZA – UNIFOR

SEMANTIC DATA SERVICES:

Hermano Albuquerque lira

FUNDAÇÃO EDSON QUEIROZ

UNIVERSIDADE DE FORTALEZA - UNIFOR

Hermano Albuquerque Lira

SEMANTIC DATA SERVICES — Uma abordagem para acesso e

Dissertação apresentada ao curso de Mestrado em

Orientador: Prof. Dr. Pedro Porfírio Muniz Farias

Dissertação (mestrado) – Universidade de Fortaleza, 2014.

1. Web semântica. 2. Internet. 3. Interface homem-máquina. I. Farias, Pedro

“Suas crenças se tornam seus pensamentos

Dedico este trabalho aos meus pais,

Gostaria de expressar a minha gratidão aos professores da banca avaliadora, Angelo

Neste trabalho, propomos os serviços de dados semânticos (Semantic Data Services –

Um diferencial do SDS é que, enquanto outras abordagens adotam a suposição de

Palavras-chave: Serviços de acesso a dados; Dados interligados; interface SERIN; Verifica-

Keywords: Data Services; Linked Data; SERIN; Integrity Constraint Check.

Figura 19: O conjunto de instâncias que compõe um comprovante de matricula e a interface

Tabela 1: Origens e destinos de voos. ...................................................................................... 16

Listagem 1: Ontologia com uma restrição de cardinalidade definida. ..................................... 27

Lista de Figuras ....................................................................................................................... ix

Lista de Tabelas ....................................................................................................................... xi

1.1 Motivação ................................................................................................................ 1

1.2 Objetivos .................................................................................................................. 5

1.3 Contribuições ........................................................................................................... 6

1.4 Estrutura da Dissertação .......................................................................................... 7

2 Dados Interligados ............................................................................................................... 8

2.1 Introdução ................................................................................................................ 8

2.2 Suposições Utilizadas nas Especificações dos Dados Interligados ......................... 9

2.2.1 Web Semântica ......................................................................................... 10

2.2.2 RDF ........................................................................................................... 11

2.2.3 Ontologia ................................................................................................... 11

2.2.4 Espécies de OWL ...................................................................................... 12

2.2.5 Lógica Descritiva ...................................................................................... 13

2.2.6 Suposições de Mundo Aberto e de Mundo Fechado................................. 14

2.2.7 Suposição de Nome Único ........................................................................ 17

2.2.8 Suposição de Mundo Fechado Localmente .............................................. 18

2.3 Tipos de acesso a dados interligados ..................................................................... 19

2.3.1 Serviços de acesso por consulta ................................................................ 20

2.3.2 Serviços de acesso por Dump.................................................................... 21

2.3.3 Serviços de acesso em nível de entidade .................................................. 21

2.4 Suporte à escrita para dados interligados............................................................... 23

2.5 Verificação da integridade semântica .................................................................... 25

2.6 Integração entre abordagens de suporte à escrita e verificação de integridade ..... 28

2.7 Sumário .................................................................................................................. 29

3 Serviços de Dados Semânticos .......................................................................................... 30

3.1 Introdução .............................................................................................................. 30

3.2 Usando URIs para Acessar Dados Interligados ..................................................... 31

3.3 Interface Semântica RESTful ................................................................................ 32

3.3.1 Separação do Conhecimento ..................................................................... 33

3.3.2 Instância RDF: Uma unidade de recuperação de informação ................... 34

3.3.3 Integridade Semântica ............................................................................... 36

3.3.4 Anotações para manipulação dos dados .................................................... 37

3.3.5 Convenção de Endereçamento .................................................................. 38

3.4 Cenário de Uso ...................................................................................................... 39

3.5 Sumário .................................................................................................................. 46

4 Restrições de Integridade na Interface SERIN ............................................................... 47

4.1 Introdução .............................................................................................................. 47

4.2 Restrições integridade via interface SERIN .......................................................... 48

4.3 Anotações para restrição de integridade ................................................................ 49

4.3.1 Anotação NotNull ...................................................................................... 49