Capítulo

9

Web Semântica: Conceitos e Tecnologias

Fernando Wagner Filho e Bernadette Farias Lóscio

Abstract

With the advent of the Web 2.0, the amount of data available on the Web is growing in an exponential way, increasingly the need for a way to organize and dispose these data, in order to integrate and share them easily. Also is important that applications that use these data be able to interpret them to automate tasks and facilitate the navigation on the Web. In this context, the Semantic Web is meant to be a gradual evolution of the current Web, where the data will be easily processed by applications.

Resumo

Com o advento da Web 2.0, o volume de dados disponível na Internet vem aumentando de forma exponencial, tornando cada vez mais necessária uma forma de organizar e dispor estes dados de maneira que seja possível integrá-los e compartilhá-los com facilidade. Além disso, a fim de automatizar tarefas e facilitar a navegação do usuário é importante que as aplicações que fazem uso desses dados sejam capazes de interpretá-los. Neste contexto, surgiu o conceito de Web Semântica, que se propõe a ser uma evolução gradual da Web atual, onde os dados poderão ser facilmente processados pelas aplicações e técnicas avançadas poderão ser utilizadas a fim de tirar proveito desta representação.

.

9. Web Semântica

O advento da Web 2.0 trouxe aos usuários uma melhor forma de comunicação e interação, popularizando ainda mais o acesso a Internet e incentivando tanto a colaboração intelectual quanto de recursos por parte dos usuários.

Como conseqüência direta deste comportamento, o volume de dados disponíveis na Web vem crescendo em quantidade exponencial. Para prover acesso a este grande volume de dados, mecanismos para busca de informações, amplamente utilizados hoje em dia, como Google, usam estratégias baseadas em busca por palavra-chave. Apesar de amplamente difundidas e utilizadas estas estratégias possuem sérios problemas como[10]:

• Alta sensibilidade à sintaxe e pouca precisão: os mecanismos de busca não levam em consideração a semântica do domínio, e isto pode causar o retorno de inúmeras ocorrências irrelevantes. Dessa forma, as ocorrências relevantes recuperadas geralmente são acompanhadas de milhares de outras ocorrências com pouca ou nenhuma relevância.

• Organização ineficiente dos dados: informações e recursos relevantes podem não estar relacionados e, em conseqüência, aparecerão separadamente no resultado da consulta. Isto pode exigir do usuário várias consultas extras e uma triagem manual dos documentos resultantes.

Diante deste cenário, surgiu a idéia da Web Semântica, que tem como um dos seus principais objetivos prover meios para organizar os dados e permitir que estes possam ser interpretados pelos computadores. Dessa forma será possível melhorar os resultados das buscas e facilitar a automação de tarefas relevantes, evitando, sempre que possível, o desperdício de tempo e fazendo com que tanto os dados quanto as máquinas sejam utilizados de forma mais inteligente.

Para ilustrar um exemplo de aplicação da Web Semântica, imagine que um usuário deseja viajar de uma localidade a outra. Para isso terá que pegar um avião e depois ficar hospedado em um hotel. Com o advento da Web Semântica, será possível realizar uma busca pela passagem mais barata para o destino em questão, incluindo as restrições de horário de saída e chegada. Posteriormente, uma busca pelo hotel mais adequado às necessidades do usuário também poderá ser feita sem que haja inúmeras intervenções ou triagens humanas.

Em 2001, Berners-Lee [8] definiu o conceito de Web Semântica bem como uma possível arquitetura para aplicações sob o mesmo contexto. A arquitetura passou por várias modificações e a sua configuração atual é ilustrada na Figura 9.1.

Figura 9.1. Arquitetura atual da Web Semântica

A arquitetura mencionada é separada em camadas, onde cada uma delas possui uma determinada função. Outro fato interessante é a alta interoperabilidade entre as mesmas. Abaixo, uma breve explicação das funcionalidades de cada uma destas camadas:

• Camada URI/IRI: Permite identificar unicamente cada recurso(ex: figures e páginas HTML) disponível na Web através de um endereço (Universal Resource Identifier);

• Camada XML: Permite a criação de marcações para descrição de informações. A sintaxe das camadas superiores é baseada em XML;

• Camada RDF: Provê um modelo de descrição lógica de dados permitindo descrever assertivas e informações sobre um determinado recurso;

• Camada RDFS: Permite a criação de um vocabulário para a camada RDF. Com o RDFS, é possível criar hierarquia de classes e propriedades;

• Camada da Ontologia: Estende a camada RDFS, provendo um maior nível de expressividade para a definição da semântica das informações;

• Camada de Consulta: Responsável prover meios para a realização de consultas sobre o modelo de dados RDFS/Ontologia;

• Camada de Regras: Provê um mecanismo de criação de relações entre recursos que não podem ser descritas diretamente na ontologia;

• Camada Lógica: É responsável pelo raciocínio e execução de inferências lógicas a partir da semântica previamente descrita;

• Camada de Prova e Confiança: Camada que provê um mecanismo para avaliar o nível de confiabilidade das fontes de recursos e informações;

• Camada de Aplicação: Camada que permite a interação entre o usuário e a aplicação Web Semântica.

Uma questão que merece destaque no contexto de Web Semântica é o uso de ontologias, que são utilizadas para prover uma correta interpretação do significado dos dados. Na Ciência da Computação, uma ontologia pode ser descrita como sendo uma especificação explícita e formal de um domínio a qual se tem interesse em representar. As ontologias são baseadas em lógica descritiva, consistindo de conceitos (classes) e relacionamentos (propriedades) entre estes conceitos [10].

No domínio de uma universidade, por exemplo, os termos professor, aluno, funcionário, disciplina são exemplos de conceitos existentes em uma possível ontologia para este domínio. Como exemplos de relacionamento entre estes conceitos, podemos citar que um professor ensina um aluno, um aluno cursa uma disciplina, entre outros.

Dentro de uma ontologia, vale destacar o relacionamento hierárquico entre conceitos, consistindo de classes e subclasses. Similar à orientação a objetos, toda subclasse herda as características de sua classe pai.

No contexto da Web Semântica, o uso de ontologias provê uma série de vantagens como por exemplo a possibilidade de realização de inferências para a descoberta de novas informações. Outro grande benefício é o fato de que as ontologias são extensíveis, ou seja, é possível estender uma ontologia de modo a adaptá-la para modelar o domínio de interesse. Para exemplificar tal característica, suponha que se tenha interesse em descrever um domínio com informações sobre computadores. Neste caso, se existir uma ontologia mais geral que descreve equipamentos, então será possível estendê-la para que seja possível descrever dados sobre computadores.

Entretanto, para que a Web Semântica torne-se uma concreta realidade, é necessário que haja uma padronização de tecnologias. Neste contexto, o W3C (World Wide Web Consortium) e a comunidade acadêmica têm unido esforços no sentido de criar, disponibilizar e padronizar linguagens e tecnologias para garantir a correta e melhor interoperabilidade possível. Neste capítulo, serão apresentados os conceitos básicos relacionados à Web Semântica, bem como algumas das principais tecnologias atualmente disponíveis para o desenvolvimento de aplicações neste contexto.

O restante deste capítulo está organizado como se segue: a Seção 9.2 apresenta alguns conceitos básicos relacionados à XML; a Seção 9.3 aborda o conceito de namespaces; as seções 9.4 e 9.5 apresentam RDF e RDFS respectivamente; a Seção 9.6 descreve brevemente a linguagem de consulta SPARQL; a Seção 9.7 apresenta a linguagem OWL; a Seção 9.8 discute rapidamente o uso do SWRL e o papel dos reasoners.

9.1. Conceitos básicos de XML

XML é uma linguagem de marcação que, diferentemente do HTML, permite a criação e o uso de tags personalizadas, fornecendo assim uma maneira simples de organizar e estruturar os dados existentes em uma determinada aplicação [1][25]. De posse dos dados estruturados, é possível estabelecer uma comunicação entre aplicações, permitindo a cooperação entre as mesmas para execução de tarefas complexas. Atualmente XML é a linguagem padrão recomendada pela W3C para troca de dados via Web.

A Web Semântica exige uma descrição formal da semântica dos dados, de tal forma a evitar ambigüidades e permitir a interpretação de informações por parte das

aplicações. Neste contexto, XML provê uma sintaxe bem definida, sendo atualmente utilizado na maioria das aplicações existentes na Web.

A Figura 9.2 exibe trechos de documentos HTML e XML que exibem informações relacionadas a professores. É possível verificar que no documento HTML a maior preocupação é com a aparência dos dados e em como eles serão exibidos para o usuário. Por outro lado, no documento XML, o objetivo principal consiste em estruturar os dados de tal forma a possibilitar o processamento destes. Dessa forma, é possível saber que o dado “12345” é referente ao ID do professor em questão, bem como “Fernando Wagner” trata-se do nome deste mesmo professor. Vale ressaltar que a sintaxe do XML é bem formal e possui uma série de regras a serem obedecidas. Um documento XML que segue todas as regras sintáticas da linguagem é chamado de documento XML bem formado.

Figura 9.2. Trechos de código HTML e XML destacando os dados de um professor

Por outro lado, XML permite estruturar um mesmo conjunto de dados de formas diferentes. A Figura 9.3, por exemplo, mostra uma maneira alternativa de representação das informações relacionadas a um professor. Tal característica pode levar a discordância entre aplicações além de uma possível confusão na hora de capturar os dados estruturados.

Figura 9.3. Documento XML alternativo ao da Figura 9.2

Para evitar este tipo de problema, foram propostas linguagens para definição de esquemas XML, que são uma espécie de contrato, onde todas as partes envolvidas por um contexto de aplicação devem escrever seus documentos XML seguindo o padrão de estruturação especificado no esquema XML correspondente. Dentre as linguagens para definição de esquemas XML, destacam-se DTD e XML Schema.

Um esquema especifica quais elementos e atributos são permitidos em um determinado documento XML, além da maneira como estes devem estar. A Figura 9.4 mostra um exemplo de um esquema para o documento XML da Figura 9.2.

Figura 9.4. Documento XML Schema correspondente ao XML da Figura 9.2

O XML Schema foi desenvolvido com o mesmo propósito do DTD. Porém, este provê uma linguagem bem mais rica para a definição de esquemas XML. Uma vantagem é que XML Schema é baseado em XML, o que aumenta a interoperabilidade e não exige conhecimento prévio de outro tipo de linguagem para definição de esquemas. Além disso, é possível manipular um arquivo XML Schema usando um editor XML ou uma API como DOM ou SAX. O XML Schema é uma recomendação da W3C desde 2001 que visa substituir o DTD.

Documentos XML que são bem-formados e estão de acordo com o esquema especificado são chamados de documentos válidos. A aplicação responsável por executar esta verificação é chamada de Parser. Caso haja algum erro de sintaxe ou alguma desconformidade entre o documento XML e o esquema correspondente, o parser acusará o erro.

9.3. Namespaces

Atualmente, a forma mais utilizada de troca de dados pela Web é através de documentos XML. Tecnicamente, documentos XML podem utilizar vários esquemas para estruturação de seus dados, ou seja, um documento XML pode fazer referência a vários esquemas XML.

Na maioria dos casos, os esquemas são desenvolvidos por vários grupos distintos. Como as fontes desconhecem os outros esquemas envolvidos na especificação da estrutura dos documentos XML, ambigüidades podem ser geradas, como por exemplo, a declaração de tags de mesmo nome, mas com semânticas distintas. Nestes casos, o parser não saberá como validar corretamente estes elementos, pois não conseguirá fazer a distinção a qual esquema o elemento faz referência.

Para resolver problemas como este, foram criados os chamados namespaces, os quais são URIs que referenciam o esquema do qual o elemento faz parte.

A Figura 9.6 ilustra um exemplo da utilização de namespaces. Prefixos que referenciam o namespace são declarados no elemento raiz do documento XML, como em destaque na Figura 9.6. Neste caso o parser tem condições de identificar qual elemento titulo trata da titulação acadêmica e qual trata da titulação como empregado da universidade.

Figura 9.5. Exemplo utilizando namespace

9.4. RDF – Resource Description Framework

Apesar de ser uma recomendação do W3C amplamente utilizada em diversas aplicações, XML não possui os requisitos necessários para descrever adequadamente a semântica de uma informação. A forma como os elementos devem estar relacionados, bem como a definição significado dos mesmos fica a cargo do desenvolvedor.

O modelo de dados RDF foi proposto como uma possível solução para esta limitação de XML. Freqüentemente referenciado como uma linguagem, o mais correto seria afirmar que o RDF é um modelo de dados que possibilita a definição de afirmações, chamadas sentenças, sobre um recurso.

Entende-se por um recurso, “qualquer coisa” sobre a qual se quer expressar uma idéia. Um recurso pode estar relacionado com dados ou com outros recursos através das sentenças. Uma sentença é estruturada no formato sujeito + predicado + objeto onde:

• Sujeito: Tem como valor o recurso do qual se quer escrever uma sentença.

• Predicado: Especifica um relacionamento entre sujeito e objeto. O predicado é especificado através de propriedades, que são relações binárias, geralmente nomeadas por um verbo e permitem relacionar um recurso a dados ou a outros recursos.

• Objeto: Denomina o recurso ou dado que se relaciona ao sujeito.

Devido ao seu formato, uma sentença é freqüentemente chamada de tripla. Assim sendo, um documento RDF pode ser visto como um conjunto de triplas, onde estas descrevem informações sobre os recursos envolvidos no domínio de interesse. A Figura 9.6 mostra uma maneira abstrata de se visualizar triplas.

Figura 9.6. Forma abstrata de visualizar triplas.

As triplas representadas na Figura 9.6 contêm informações sobre dois recursos. A primeira tripla informa que o recurso “p91002043177” possui nome Berna Farias. A

segunda tripla descreve um segundo recurso “CK120”, cujo nome é “Banco de Dados I”. A terceira tripla descreve um relacionamento entre os dois recursos criados através do predicado “EnsinadoPor”. Os elementos de RDF para descrição de triplas são:

• <rdf:Description>: Usado toda vez que se quer escrever uma tripla acerca de um recurso.

• <rdf:ID>: Responsável pela declaração de um recurso.

• rdf:resource: Atributo utilizado para fazer referência a outros recursos existentes.

Documentos RDF também podem ser visualizados como grafos, onde cada recurso e/ou literais existentes são os nós e as propriedades são as arestas. A Figura 9.7 mostra as triplas da Figura 9.6 dispostas sobre a forma de um grafo.

Figura 9.7. Visualização de triplas através de um grafo

Considere agora a Figura 9.8 que contém o exemplo de triplas descritas utilizando a sintaxe de XML. A linha 1 mostra a versão da sintaxe XML utilizada. As linhas 2 e 3 exibem o elemento raiz de um documento RDF, juntamente com os namespaces que serão utilizados. Por padrão o elemento raiz de todo documento RDF é <rdf:RDF> . A linha 5 mostra a criação de um recurso cujo o ID é P91002043177. Na linha 7, descrevemos a mesma informação da contida na Figura 9.6, de que o recurso criado na linha 5 tem por nome “Berna Farias”. Vale salientar a importância do namespace “uni”, especificando o domínio das informações que o recurso em questão fará uso.

Figura 9.8. Trecho de um documento RDF.

Nas linhas 11 à 14 descrevemos um recurso como uma disciplina. Podemos verificar que não é obrigatório o uso do <rdf:ID> para a criação do recurso, ou seja,

podemos utilizar a tag <rdf:Description> juntamente com o atributo rdf:about para criar e escrever informações acerca do recurso.

É uma boa prática utilizar rdf:resource ao invés de escrever o valor do elemento. Isto fortalece o relacionamento entre os recursos. No caso da Figura 9.8, por exemplo, não seria interessante escrever <uni:ensinadoPor>P91002043177</ uni:ensinadoPor >.

Outra importante funcionalidade presente no RDF são os containers. Eles permitem certa propriedade fazer referência a mais de um recurso. Estes são divididos em 3 formas:

• rdf:Bag: Simboliza um conjunto de recursos ou literais onde permite-se repetições de elementos e a ordenação disposta não é relevante.

• rdf:Seq: Similar ao bag, porém a ordem dos elementos é relevante.

• rdf:Alt: Um conjunto de recursos onde apenas um destes poderá ser escolhido como real valor da propriedade.

A Figura 9.9 mostra um exemplo do uso do container bag. No exemplo o container foi usado para especificar os componentes de um projeto. É importante ressaltar que o RDF é um modelo de dados que possibilita escrever triplas sobre qualquer recurso em qualquer domínio, ou seja, o RDF é independente de domínio.

Atualmente, o RDF utiliza a sintaxe XML em sua especificação. Porém, nada impede que os conceitos do RDF sejam implementados utilizando outras sintaxes.

Figura 9.9 Uso do container <rdf:Bag>

9.5. RDFS – Resource Description Framework Schema

RDF provê um modelo de dados que permite descrever sentenças sobre domínios de interesse. Apesar disso, um documento RDF não pode ser considerado uma ontologia. Isto porque não é possível conceitualizar um domínio como proposto na definição de ontologias [6]. Não é possível especificar em RDF, por exemplo, que todo docente é um funcionário, ou que os participantes de um projeto devem ser todos pesquisadores. Além disso, RDF dá margem a certas inconsistências como a ilustrada na Figura 9.10.

O código da Figura 9.10 é validado com sucesso pelo parser RDF. Porém, a semântica do documento contém uma falha grave. A tripla representada pelas linhas 9-

11 diz que um recurso que representa um conjunto de indivíduos é do tipo deste indivíduo, quando o mais sensato seria expressar o oposto.

Figura 9.10. Possível inconsistência no RDF

Neste contexto, RDFS visa solucionar tais problemas provendo construtores que permitem especificar formalmente um esquema. A idéia principal é unir RDFS + RDF de tal forma que todas as sentenças descritas em RDF obedeçam à semântica descrita no esquema especificado em RDFS. Este esquema nada mais é do que a modelagem do domínio de interesse. Alguns construtores de RDFS são citados e descritos abaixo:

• <rdfs:Class> - Permite a criação de classes. O conceito de classes em RDF é similar ao existente na programação orientada a objetos, ou seja, uma classe descreve um conjunto de indivíduos/instâncias que possuem as mesmas características e comportamentos. A existência das classes é muito importante para o contexto das ontologias, uma vez que estas permitem explicitar generalizações, além de impedir inconsistências semânticas como a ilustrada na Figura 9.10.

• <rdfs:subClassOf> - Permite especificar especializações entre classes, inclusive heranças múltiplas. Assim como na orientação a objetos, uma subclasse herda todas as características das classes pai. Podemos expressar, por exemplo, que um docente é subclasse de funcionário, ou seja, todo docente também é um funcionário. Vale destacar o caráter transitivo deste construtor, ou seja, dada três classes A, B e C, se A é subclasse de B e B é subclasse de C, então podemos inferir que A é subclasse de C.

RDF provê um construtor para declaração de propriedades. Porém, RDFS estende este construtor fazendo uso de outros novos construtores, gerando maior poder de expressividade para a explicitação da semântica de uma propriedade. Os construtores utilizados na extensão são citados abaixo:

• <rdfs:Domain> - Define quais classes de indivíduos serão aceitas como sendo o sujeito em triplas envolvendo a propriedade. Este conjunto de classes é denominado de “domain”

• <rdfs:Range> - Define quais classes de indivíduos ou valores literais serão aceitos como sendo o objeto em triplas envolvendo propriedade.

• <rdfs:subPropertyOf> - Caracteriza uma hierarquia entre propriedades. Análogo ao conceito de subclasse para classes. Este conjunto de classes ou valores literais é denominado de “range”.

As subpropriedades herdam os conjuntos “domain” e “range” de suas propriedades mais gerais. Considere o exemplo da Figura 9.11.

Figura 9.11. Declaração de Domains, Ranges e subProperty.

As linhas 8 – 11 apresentam declarações de duas classes, “Pesquisador” e “Evento”, juntamente com uma instância de cada uma destas classes. Nas linhas 13 – 16 é declarada uma propriedade “Envolve” que relacionará instâncias de pesquisadores com instâncias de eventos. Logo após, as linhas 18 – 20 apresentam a declaração de outra propriedade, chamada “Organiza”. Os conjuntos “domain” e “range” desta nova propriedade não estão declarados de maneira explicita, mas pode-se inferir que estes têm como valores os conjuntos de pesquisadores e eventos respectivamente, pelo fato de que a propriedade “Organiza” é uma subpropriedade de “Envolve”.

Da mesma maneira que subclasses herdam as características de suas classes pai, as propriedades também herdam as características das suas propriedades pai.

Pelo exemplo da Figura 9.11, é possível notar que RDFS expande os horizontes de RDF, de tal forma que é possível explicitar e inferir outras informações relevantes ao domínio de interesse. Por este motivo é válido ressaltar que o modelo de dados constituído da união de RDF e RDFS tem uma maior expressividade do que o modelo RDF por si só. Vale também destacar a declaração de namespaces no elemento raiz (linhas 2 - 6) bem como o seu uso ao longo do documento, visando distinguir o contexto dos elementos utilizados.

Apesar do aumento da expressividade advindo da união de RDF com RDFS, isto ainda não é o suficiente para prover uma rica descrição semântica acerca de um domínio de interesse. É necessário que haja um vocabulário mais amplo, que possibilite a especificação de regras que poderão ser usadas pelo reasoner para inferência novos fatos.

Em RDF/RDFS não é possível, por exemplo, restringir a cardinalidade de uma propriedade. Não é possível dizer que um time de futebol contém no mínimo onze jogadores, por exemplo. Também não há expressividade suficiente para classificar um indivíduo mediante certo tipo de valor que este contém em alguma propriedade.

A próxima seção aborda SPARQL, a linguagem recomendada pela W3C para consultas por informações em documentos RDF/RDFS. Em seguida, será introduzida a linguagem OWL (Ontology Web Language), que disponibiliza um rico vocabulário de construtores permitindo aumentar consideravelmente a expressividade para descrição de ontologias.

9.6. SPARQL – Linguagem para consultas por triplas RDF

Assim como os sistemas de bancos de dados relacionais fazem uso do SQL para consultar registros nas suas bases de dados, o SPARQL é a linguagem recomendada pelo W3C para recuperação de informações em documentos RDF/RDFS

O RDF e RDFS permitem que uma determinada informação possa ser modelada de diversas maneiras, apesar de sempre dispô-la na forma de uma tripla. Logo, se faz necessário ter uma linguagem de consulta que consiga recuperar os dados de interesse levando em consideração a semântica das sentenças, e não a sintática. Considere o seguinte trecho de um documento:

<rdf:Description rdf:about="949318">

<rdf:type rdf:resource="&uni;Professor"/>

<uni:name>Davi Cavalcante</uni:name>

<uni:title>Doutorado</uni:title>

</rdf:Description>

O trecho acima cria uma instância do tipo “Professor” e determina seu nome, Davi Cavalcante, e sua titulação, Doutorado. Existe uma maneira equivalente de especificarmos estas mesmas sentenças, como descrito a seguir:

<uni:Professor rdf:about="949318">

<uni:name> Davi Cavalcante </uni:name>

<uni:title> Doutorado </uni:title>

</uni:Professor>

É possível perceber que os dois trechos declaram triplas que possuem o mesmo significado, mas são expressos de forma diferente. As linguagens para consulta XML existentes atualmente não dão suporte para essa variedade sintática, o que requer a especificação de uma linguagem de consulta que dê suporte a estes níveis de expressividade e que entenda a semântica do modelo RDF/RDFS.

Apesar de existirem outras linguagens de consulta (SeRQL, RQL, etc..) mais antigas, maduras e com maior poder de expressividade que o SPARQL, estas ou foram projetadas para se trabalhar em um domínio específico ou são interpretadas apenas por algumas poucas ferramentas, o que acaba resultando em uma baixa interoperabilidade.

Semelhante ao SQL, o SPARQL possui uma estrutura SELECT-FROM-WHERE onde:

• SELECT: Especifica uma projeção sobre os dados como a ordem e a quantidade de atributos e/ou instâncias que serão retornados.

• FROM: Declara as fontes que serão consultadas. Esta cláusula é opcional. Quando não especificada, assumimos que a busca será feita em um documento RDF/RDFS particular.

• WHERE: Impões restrições na consulta. Os registros retornados pela consulta deverão satisfazer as restrições impostas por esta cláusula.

O resultado de uma consulta SPARQL pode ser encarado como um subgrafo resultante da execução da consulta sobre o grafo que representa o modelo. Considere por exemplo o grafo apresentado na Figura 9.12 extraído de [15].

Figura 9.12. Representação das instâncias de um domínio

O grafo da Figura 9.12 representa a relação entre as instâncias de uma ontologia cujo domínio é focado na descrição e formalização de escritores. O subgrafo destacado em negrito pode ser encarado, por exemplo, como o resultado de uma consulta que retorna o escritor que escreveu o livro King Lear e é casado com AnneHathaway. Esta consulta pode ser descrita abaixo:

• PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

PREFIX wri: <http://www.mydomain.org/writers#>

SELECT ?x

WHERE

{

?x rdf:type escritor

AnneHathaway wri:married ?x

?x wri:wrote KingLear

}

Neste exemplo, ?x é uma variável que representa o conjunto de recursos que será retornado como resposta da consulta. As cadeias de caracteres “?x wri:wrote KingLear”, “AnneHathaway wri:married ?x” e “?x wrote KingLear” são chamados de padrões de

tripla (triple patterns). No contexto de SPARQL, os padrões de triplas são usados para designar condições de retorno na cláusula WHERE. Os significados dos padrões de tripla podem ser interpretados em linguagem natural. No caso da consulta acima, tais significados são respectivamente:

• O recurso é escritor?

• AnneHathaway foi casado com o recurso?

• O recurso escreveu King Lear ?

Todos os recursos que satisfizerem a essas três perguntas serão retornados pela consulta em questão. Segue abaixo outro exemplo de consulta SPARQL. A consulta irá retornar todas as classes existentes no modelo da Figura 9.12:

• PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?c

WHERE

{

?c rdf:type rdfs:Class .

}

A consulta acima é bem geral e pode ser utilizada em qualquer esquema, independente do domínio modelado. Outro exemplo similar seria escrever uma consulta que retornasse todas as propriedades existentes no modelo e assim por diante. É possível formular consultas de modo a retornar informações complexas ou mais simples, dependendo do objetivo que se queira alcançar. Outro exemplo de consulta consiste em fazer uma projeção das propriedades de dados de um determinado modelo para obtenção de seus valores:

• SELECT ?nome ?email

WHERE

{

?x rdf:type uni:Professor ;

uni:nome ?nome ;

uni:email ?email .

}

A consulta acima retornará o nome e o email de todos os professores descritos. Além das cláusulas básicas “SELECT, FROM e WHERE”, tem-se outras cláusulas opcionais com o objetivo de aumentar a expressividade das consultas. São estas:

• FILTER: Operador usado para comparações booleanas entre instâncias. Ex:

SELECT ?n

WHERE

{

?x rdf:type uni:Curso ;

uni:EnsinadoPor:949352 .

?c uni:nome ?n .

FILTER (?c = ?x).

}

A consulta acima retorna o nome de todos os cursos no qual o professor de código 949352 leciona.

• OPTIONAL: Torna uma determinada restrição na cláusula WHERE opcional. Ex:

SELECT ?nome ?email

WHERE

{

?x rdf:type uni:Professor ;

uni:nome ?nome .

OPTIONAL { ?x uni:email ?email }

}

Se a cláusula OPTIONAL não fosse usada na consulta acima, seriam retornados todos os professores que, obrigatoriamente, possuem um nome e um email. Caso um professor não tivesse um email, este não seria retornado no resultado final da consulta. Com o uso da cláusula, serão inclusos no resultado final os professores que possuem um nome, mas não possuem email.

9.7. OWL - Ontology Web Language

A expressividade RDF/RDFS, descrita nas seções anteriores, é bastante limitada. Basicamente, RDF descreve sentenças sem que haja qualquer descrição formal de um domínio, e o RDF Schema somente suporta hierarquia de classes e propriedades. No contexto da Web Semântica, a camada da ontologia visa suprir essas limitações provendo uma maior expressividade para descrever um domínio de interesse.. Abaixo são descritas algumas dessas características

• Restrições de propriedades: Muitas vezes precisamos impor restrições nos valores que uma propriedade pode assumir. Por exemplo, não conseguimos dizer em RDF/RDFS que um time de futebol tem que ter, no mínimo, onze jogadores para poder disputar uma partida.

• Disjunção de classes: No domínio-alvo pode acontecer de classes (conceitos) serem disjuntos. Por exemplo, homem e mulher são dois conceitos disjuntos, pois uma pessoa não pode ser do sexo masculino e feminino ao mesmo tempo. Em RDF/RDFS, é possível somente expressar relações de hierarquia como mulher é subclasse de pessoa.

• Combinação entre classes: RDF/RDFS não permite que se criem novos conceitos utilizando uma combinação de conceitos já especificados usando, por exemplo, a união ou interseção destes.

• Características de propriedades: Também não é possível especificar na camada de RDF/RDFS algumas características de propriedades como, por exemplo, a transitividade de valores.

Assim, faz-se necessário uma linguagem com sintaxe bem definida e que seja mais rica que o RDF/RDFS em termos de expressividade, oferecendo as características acima citadas sem que se perca o eficiente suporte à inferência de informações.

O OWL é a linguagem recomendada pela W3C para a especificação de ontologias. Os seus idealizadores visavam prover uma linguagem que possuísse a expressividade necessária para descrição de ontologias no suporte à Web Semântica. Esta linguagem teve sua construção baseada em duas linguagens precursoras, a DAML e a OIL, além de amplos estudos em áreas como semântica dos dados e processamento de informações em bases de conhecimento. O OWL possui três sublinguagens (também chamados de dialetos):

• OWL Full: A versão mais expressiva do OWL. Permite o uso de todas as funcionalidades disponíveis. Porém, tamanha expressividade compromete a eficácia na extração e inferência de informações bem como a decidibilidade da ontologia. Uma ontologia decidível é aquela capaz de ser processada em tempo hábil por um reasoner;

• OWL DL (Description Logic): Subconjunto da versão Full que tem como objetivo prover certo nível de expressividade sem comprometer a eficiência de tarefas como a inferência (reasoning) de informações por parte dos motores de inferência (reasoner);

• OWL Lite: A menos expressiva das versões de OWL. Tem sido muito usada para definição de domínios simples. Pode ser uma boa alternativa para migração de tesauros. A principal vantagem é a facilidade de entender e de se implementar uma ontologia usando esta versão. A desvantagem é a restrição na sua expressividade.

Os desenvolvedores de ontologias devem escolher a versão da linguagem de acordo com suas necessidades. Basicamente a escolha consiste em balancear o nível de expressividade com decidibilidade e eficiência na inferência de informações. Isto porque, quanto maior o nível de expressividade utilizado na descrição de uma ontologia, maior será a complexidade dos algoritmos envolvidos em tarefas como reasoning e busca por informações.

Desde que OWL Full provê expressividade máxima e que OWL Lite é o subconjunto menos expressivo da linguagem, é possível afirmar que:

• Toda ontologia válida em OWL Lite é também uma ontologia válida em OWL DL;

• Toda ontologia válida em OWL DL é também uma ontologia válida em OWL Full.

O padrão OWL incorpora elementos de XML e RDF, além de estruturas adicionais para o correto tratamento das ontologias como, relações entre classes, definição de restrições decardinalidade, igualdade, tipos de propriedades complexos e outros.

A seguir, uma descrição de algumas estruturas próprias da linguagem OWL para a especificação formal de ontologias:

• Object Properties: O OWL especializa as propriedades em dois tipos: Objetc Property (Propriedade de objeto) e Datatype property (Propriedade de dado). Uma propriedade de objeto carateriza-se por relacionar classes entre si. Geralmente expressas na linguagem natural por verbos Ex: Professor ensina Aluno; Professor leciona disciplina etc.

• DatatypeProperties: Outra especialização das propriedades. Relaciona uma classe a um determinado literal. Freqüentemente chamados de atributos de uma classe. Ex: Disciplina possui um número de créditos.

As propriedades de objetos por sua vez foram especializadas como parte da estratégia para aumentar a expressividade da linguagem. Estas possuem as seguintes especializações:

• TransitiveProperty: Podemos dizer que uma propriedade é transitiva. Se o par (x, y) de instâncias se relaciona através uma propriedade transitiva P, e o par (y, z) se relaciona por P, então o par (x, z) também se relacionam através de P, pela transitividade. Ex: A relação de subordinação entre funcionários pode ser modelada como uma propriedade transitiva. Se um funcionário A é subordinada à um funcionário B e este por sua vez é subordinado a um terceiro funcionário C, então infere-se que o funcionário A é subordinado ao funcionário C.

• SymmetricProperty: As propriedades podem ser declaradas simétricas, isto é, se P é simétrica, e o par (x, y) se relacionam por P, então (y, x) também se relacionam por P. Essa característica impõe que o domínio e alcance de P não podem ser arbitrários. Ex: O matrimônio é uma relação entre duas pessoas que pode ser modelada em uma propriedade simétrica. Se uma pessoa de nome Gabriel é casada com outra pessoa de nome Bárbara, a recíproca será verdadeira.

• FuncionalProperty: Dado um sujeito qualquer, uma propriedade funcional obriga a existência da restrição de unicidade para o valor do objeto. É equivalente a afirmar que a propriedade tem a restrição de mínima cardinalidade igual a 0 e máxima cardinalidade igual a 1. Ex: Um curso de graduação é chefiado por apenas um coordenador. .

• InverseFuncionalProperty: Representa a inversa da propriedade funcional. Usado quando se quer restringir unicamente o valor do sujeito em relação a valores de objetos. Ex: Uma classe de códigos especiais funciona como números de serial para ativação de uma classe de produtos. Modelando este exemplo como propriedade inversamente funcional, apenas uma instância de código especial poderá estar relacionada com vários produtos.

OWL permite a criação de novas classes a partir de classes previamente existentes. É possível especificar que:

• unionOf: Uma nova classe como sendo a união de duas ou mais classes. Ex: A classe de acadêmicos é a união das classes dos docentes e dos discentes existentes em uma universidade.

• intersectionOf: Alternativamente, uma classe pode surgir a partir da interseção de duas ou mais classes. Ex: Pode-se especificar uma nova classe de alunos professores através da interseção das classes docente e discente.

• complementOf: Permite declarar classes complementares umas as outras. Ex: A classe de servidores administrativos de uma universidade pode ser especificada

como o complemento da classe dos docentes em relação à classe de todos os funcionários.

• oneOf: Uma classe pode ser descrita como uma enumeração de indivíduos. Por exemplo, a classe diasDaSemana pode ser declarada como oneOf dos elementos Domingo, Segunda, Terça, Quarta, Quinta, Sexta, e Sábado.

Também é possível restringir os valores do Domain e Range de propriedades através restrições de propriedades. É muito usado quando se quer definir uma restrição para os valores de uma propriedade, de tal forma que esta restrição se aplique a um determinado conjunto de elementos.

• allValuesFrom: Restringe todos os valores de uma propriedade a uma determinada classe. Equivale ao uso do quantificador um universal nos valores das propriedades Ex: Disciplinas obrigatórias só podem ser lecionadas por professores efetivos.

• someValuesFrom: Determina que deve existir pelo menos uma instância da classe especificada como valor de propriedade. Equivale ao uso do quantificador existencial nos valores das propriedades Ex: Um professor deve lecionar pelo menos uma disciplina do curso de graduação.

• hasValue: Especifica um determinado indivíduo como valor de uma propriedade. Ex: As disciplinas de banco de dados devem ser lecionadas pela professora Vânia Vidal.

• minCardinality: Pode-se afirmar a cardinalidade mínima de valores em uma propriedade. Afirmar que a cardinalidade mínima é 0 apenas explicita que a propriedade não é obrigatória. Dizer que a cardinalidade mínima é 1, afirma a obrigatoriedade da mesma. Ex: Disciplinas têm, no mínimo, um crédito.

• maxCardinality: Também se pode afirmar a cardinalidade máxima dos valores de uma propriedade. Afirmar que a cardinalidade máxima é 0 equivale a dizer que propriedade não pode ser aplicada. Afirmar que a cardinalidade máxima é 1, implica em afirmar que só podemos ter no máximo um elemento para aquela propriedade. Ex: O máximo de créditos permitidos em uma matrícula são 32.

• cardinality: Significa afirmar que as cardinalidades mínima e máxima tem o mesmo valor. Ex: Professores efetivos têm carga-horária de exatamente 40 horas

Abaixo encontram-se mais alguns construtores disponíveis na linguagem OWL:

• equivalentClass: Pode-se afirmar que duas classes são equivalentes quando estas possuem a mesma extensão de classe, ou seja o mesmo conjunto de instâncias. Ex: Em uma universidade a classe dos professores é equivalente à classe dos docentes.

• disjointWith: Pode-se declarar que duas classes são disjuntas. Tem significado oposto ao do equivalentClass.

• equivalentProperty: É possível afirmar que duas propriedades são equivalentes quando estas possuem o mesmo significado. Ex: Tanto faz dizer que um professor ensina uma disciplina como dizer que o mesmo leciona a disciplina.

• inverseOf: Uma propriedade pode ser explicitamente descrita como inverso de outra. Isso garante a inferência de que se um indivíduo X se relaciona a outro indivíduo Y por uma propriedade P1, e P2 é o inverso de P1, então Y se

relaciona a X por P2. Muito usado para expressar a relação de voz passiva e ativa entre verbos. Ex: A propriedade “ensina” tem como inversa a propriedade “é ensinada”.

• sameIndividualAs: Permite explicitar a equivalência entre dois indivíduos.

• differentFrom: Explicita a divergência entre dois indivíduos. Importante para quando não há identificador único nas instâncias das classes.

• allDifferent: um conjunto de indivíduos pode ser declarado como diferentes entre si.

Para que haja uma melhor compreensão do leitor sobre os conceitos citados, será utilizado, como exemplo, uma pequena ontologia de domínio universidade. A idéia é verificar o uso das ontologias um caso prático. A Figura 9.13 exibe a hierarquia entre as classes que serão criadas na ontologia.

Figura 9.13. Hierarquia de classes da ontologia

A linguagem OWL é baseada em XML e permite a implementação das características acima. A seguir, serão exibidos trechos OWL do modelo descrito pela Figura 9.13 de classes. Por questão de espaço, foram suprimidas algumas declarações, além das descrições relativas às propriedades de dados.

A Figura 9.14 retrata a criação de algumas classes (Curso, Projeto, etc.) bem como suas subclasses. A criação da classe Professor merece uma atenção especial. O modelo diz que esta classe possui uma herança múltipla de Funcionário e Acadêmico.

Figura 9.14. Algumas classes e subclasses.

A Figura 9.15 mostra uma maneira de implementar essa herança. A classe Professor consiste da interseção dos indivíduos que são Funcionários e Acadêmicos.

Figura 9.15. Herança Múltipla

A Figura 9.16 exibe uma visão da ontologia na qual se destacam os relacionamentos entre as classes através das propriedades de objeto.

Figura 9.16. Classes e propriedades de objeto.

A Figura 9.17 codifica o relacionamento entre as classes Acadêmico e Projeto. Acadêmicos só podem trabalhar em apenas um projeto devido ao caráter funcional da propriedade. A propriedade “Associado” tem implementação similar a propriedade trabalha, só alterando seu Domain e Range. No caso da propriedade “Oferta”, ama disciplina só pode ser ofertada por um curso.

Figura 9.17. Propriedades funcionais e inversamente funcionais.

Por fim, a Figura 9.18 destaca o caráter transitivo da propriedade “subordinado” bem como a restrição de cardinalidade máxima no número de disciplinas que um professor pode lecionar, além da restrição de quantificador existencial na propriedade “ temTitulacao”, obrigando o acadêmico a ter pelo menos uma titulação.

Figura 9.18. Propriedades transitivas e restrições.

Algumas características presente nas ontologias se assemelham bastante com às da orientação a objetos. O conceito de classe e herança são exemplos dessa similaridade. Com isso, o uso de ferramentas como a UML podem auxiliar na visualização conceitual do esquema da ontologia, principalmente os relacionamentos entre classes e propriedades.

Nem todos os conceitos envolvidos em uma ontologia podem ser explicitamente vistos em um diagrama de classes. Um exemplo são as restrições das propriedades, onde o diagrama permite apenas a visualização das restrições de cardinalidade. As técnicas de abstração para criação de ontologias são similares às utilizadas em um projeto orientado a objetos, principalmente no que tange à aquisição do conhecimento.

9.8. SWRL - Semantic Web Rule Language

Lógica é a ciência que estuda a corretude do raciocínio, ou seja, estuda maneiras corretas de se pensar, a fim de obter conhecimentos verdadeiros [10]. Um problema

clássico de lógica consiste em, dado um conjunto de premissas (fatos conhecidos), obter uma conclusão correta, provando ou não a validade de um determinada sentença. Considere o exemplo:

1. é_Pai(x,y) :- é_filho(y,x), Homem(x).

2. é_Mãe(x,y) :- é_filho(y,x), Mulher(x).

3. temIrmão(x,y) :- ((é_Pai(z,x), é_Pai(z,y) ; (é_Mãe(z,x), é_Mãe(z,y)), Pessoa(x), Pessoa(y), Pessoa(z).

O exemplo acima descreve alguns conceitos básicos (ex: homem, mulher) e relações entre os mesmos. Em especial, a terceira definição permite saber se um indivíduo é irmão de outro, bastando apenas verificar se pelo menos um de seus pais são a mesma pessoa.

O conjunto dos conceitos de um domínio e suas relações é chamado de base de conhecimento. De posse de uma base de conhecimento bem formada e consistente, nada impede que um agente inteligente possa interpretá-la, retornando informações úteis bem como inferindo informações implícitas para o usuário. No contexto da Web Semântica, as bases de conhecimento são descritas por ontologias e os agentes inteligentes são particularmente chamados de reasoners

Na arquitetura proposta para a Web Semântica, a camada da ontologia provê suporte e expressividade suficiente para dispormos uma conceitualização de um domínio, de tal forma que se possibilite a descoberta de novas informações.

Através dos construtores descritos na seção 9.7, pode-se, por exemplo, expressar o caráter transitivo de uma propriedade, possibilitando a inferência de novos conhecimentos por parte do reasoner.

Apesar de todo o poder de expressividade proveniente das ontologias para se conceitualizar formalmente um domínio de interesse, há casos em que ainda poderá haver necessidade de meios que permitam expressar certas definições.

A camada ontológica, baseada na lógica descritiva, permite apenas a definição de classes, propriedades e restrições, não sendo possível escrever predicados complexos, com mais de uma propriedade, deixando assim, um vácuo de expressividade semântica.

Considere uma ontologia para o domínio de uma família. Na lógica descritiva usada para especificar ontologias, não é possível elaborar uma regra que expresse que o irmão do pai de uma pessoa é seu tio. Isto porque a lógica descritiva não tem o poder de selecionar valores de uma propriedade de acordo com os valores de outra propriedade (property chaining [21]). A restrição nos valores de propriedades apenas através de construtores como quantificadores universais (owl:AllValuesFrom) e existenciais (owl:SomeValuesFrom) É preciso criar uma estratégia para o desenvolvimento de regras cobrir esta deficiência.

A Web Semântica propõe uma camada lógica que visa complementar semanticamente o domínio, preenchendo as deficiências das ontologias, bem como as da lógica descritiva em geral.

A camada lógica permite a criação de regras baseadas na lógica de HORN [10], envolvendo classes e propriedades definidas na ontologia, relacionando-as de tal forma a prover um novo mecanismo para aproximar mais ainda modelagem do domínio ao

parecer do mundo real. Assim, uma regra do tipo abaixo, sanaria facilmente o problema do exemplo citado:

A regra acima diz que todo indivíduo “?x” que possui um pai “?y” e este pai tem um irmão ?z, então este indivíduo terá um tio “?z”. Os caracteres ?x,?y,?z são chamados variáveis e estes representam um conjunto de indivíduos que estão relacionados de acordo com o significado da regra expressa. Predicados unários e binários (Classes e propriedades) são chamados de átomos. A regra acima contém quatro átomos (três delas presente no corpo e uma na cabeça). Como exemplo de regra para o domínio de uma universidade, podemos citar a que se segue:

onde todo acadêmico que trabalha em um projeto será considerado um funcionário. Também é possível especificar uma regra relacionada a determinadas instâncias, como a citada abaixo:

O exemplo acima expressa que todo indivíduo que cursa computação também trabalha em um projeto específico denominado por “CID”. Com a junção das duas regras citadas, ainda é possível inferir que todos os acadêmicos que cursam computação são um funcionários, pois todos trabalham no projeto “CID”

A lógica descritiva e a lógica de Horn são ortogonais, ou seja, ambas são totalmente disjuntas entre si. Na lógica de Horn, apesar de ser possível expressar regras envolvendo várias propriedades e classes previamente especificadas, não se consegue, por exemplo, descrever que uma pessoa só pode ser um homem ou uma mulher. Por outro lado as ontologias permitem escrever um axioma que especifica esta semântica (se o OWL for utilizado para tal, poder-se-ia fazer uso do construtor owl:complementOf).

Assim, a idéia da arquitetura da Web Semântica é unir o poder de expressividade das duas lógicas, fazendo com que eventuais deficiências semânticas sejam sanadas.

Já existe um esforço da comunidade científica no que tange à tentativa de padronização da linguagem para implementação de regras. Advindo do RuleML [7] e do OWL DL, o SWRL (Semantic Web Rule Language) é uma linguagem candidata à recomendação W3C pois permite a definição de regras no contexto da camada lógica proposta pela Web Semântica. Com o SWRL é possível escrever regras no formato de cláusulas de HORN, como descrito abaixo, para a definição de regras:

onde Ai e B são fórmulas atômicas, podendo ser lidos da seguinte forma: Se A1,...,An são verdades, então B será verdade(dedução) ou se A1,...,An, então execute B(reação). As fórmulas A1,...Ai são chamadas de antecedentes ou corpo da regra. A fórmula B é chamada de conseqüente ou cabeça da regra.

Além de ser conter todo o rigor lógico necessário para a definição de regras, o SWRL é baseado em OWL, o que permite interoperabilidade entre as tecnologias.

Uma vez que a(s) ontologia(s) e suas regras estejam corretamente descritas, os chamados motores de inferência, ou reasoners, são responsáveis por varrer a ontologia por informações úteis ao usuário. Além desta varredura, os motores também possuem

outras funções como, por exemplo, checar a consistência lógica de uma ontologia. Algumas características desejáveis em um motor de inferência são [4]:

• Dinamismo: Consiste em dar suporte ao acréscimo de informações na base de conhecimento, sempre atualizando as inferências de forma a manter a corretude das informações;

• Multiplicidade: Conseguir trabalhar num domínio que possa conter uma ou mais ontologias, dando suporte a conceitos externos;

• Suporte à linguagem padrão de ontologias (OWL);

• Trabalhar o mais eficientemente possível com grandes volumes de informação.

Atualmente existem vários motores de inferência implementados em várias linguagens sendo constantemente aprimorados. Entre eles, destaca-se o Pellet [8]. O Pellet é um reasoner de código aberto escrito em java. Dentre as principais vantagens do Pellet podemos citar a portabilidade, facilidade de integração com os principais frameworks e API´s para desenvolvimento de ontologias (JENA [11], OWLAPI [24], etc.), suporte às regras SWRL, e o bom desempenho se comparado à outros motores de inferência existentes. Além disso, o Pellet está em constante aprimoramento técnico e conta também com a participação ativa dos usuários até mesmo devido a seu caráter open-source.

Referências

[1] XML: eXtensible Markup Language. Disponível em: <http://www.w3.org/XML/>. Acesso em: 10 de jul. de 2009.

[2] DTD: Data Type Definitions. Disponível em: http://www.w3schools.com/DTD/default.asp

[3] XML Schema: Disponível em: < http://www.w3.org/XML/Schema>. Acesso em: 10 de jul. de 2009.

[4] Groppe et al. (2008). “A Sparql engine for streaming RDF Data”, Third International IEEE Conference on Signal-Image Technologies and Internet-Based System

[5] Baader, F., Calvanese, D., McGuinness, D., Nardi, D. and Patel-Schneider P., editors. (2003). “The Description Logic Handbook: Theory, Implementation and Applications”, Cambridge University Press, 2nd edition.

[6] Gruber, T. (1993). “Toward Principles for the Design of Ontologies Used for Knowledge Sharing”, Knowledge Systems Laboratory, Stanford University.

[7] HORROCKS Ian, et al. (2004), “SWRL: A Semantic Web Rule Language Combining OWL and RuleML”, W3C Member Submission.

[8] SIRIN Evren, et al. (2007). “Pellet: A Pratical OWL-DL Reasoner”, Valencia, Journal of Web Semantics.

[9] BERNERS-LEE, T., HENDLER, J., LASSILA O. (2001) “The Semantic Web. ScientificAmerican”,v. 284, n. 5, p. 34-43.

[10] ANTONIOUS Grigoris; Harmelen Frank van. (2008). “A Semantic Web Primer”, Second Edition,Cambridge, MIT Press, Massachusetts.

[11] REYNOLDS Dave. “Jena 2 Inference Support”,Disponível

em: <http://jena.sourceforge.net/index.html>.

[12] Elmasri, R. and Navathe, S. B. (2003) “Fundamentals of database systems”, 4th. edition, Addison-Wesley.

[13] G Klyne, JJ Carroll, B McBride. (2004). Resource description framework (RDF): Concepts and abstract syntax. Disponível em: http://www.w3.org/TR/rdf-concepts/

[14] RDF Tutorial. Disponível em: http://www.w3schools.com/rdf/

[15] ALLEMANG Dean, Hendler, Dim.(2008). Semantic Web for the Working Ontologist, 1st edition. Morgan Kaufmann publ., Amsterdam, Netherlands.

[16] LACY Lee W. (2004). Representing information using the Web Ontology Language, 1st edition. Trafford. Michigan, United States.

[17] SIRIN Evren, et al. (2007) “Pellet: A Pratical OWL-DL Reasoner”,Valencia, Journal of Web Semantics.

[18] PARSIA Bijan, Sirin, et al. (2004). “Cautiouly Approaching SWRL”, University of Maryland, Baltimore, United States.

[19] D. Brickley, R.V. Guha. (2004). “Resource Description Framework (RDF) Schema”. Disponível em: http://www.w3.org/TR/rdf-schema/

[20] Hebeler et al. (2009). Semantic Web Programming. Wiley publishing Inc. Indianápolis, Canada.

[21] Segaran et al .(2009). Programmimg the Semantic Web. O´Reilly publishing. New York, United States of America.

[22] Pollock Jeffrey, T. (2009). Semantic Web for Dummies. Wiley publishing Inc. Indianápolis, Canada.

[23] Matthew Horridge, Sean Bechhofer, Olaf Noppens.(2007). Igniting the OWL 1.1 Touch Paper: The OWL API. OWLED 2007, 3rd OWL Experienced and Directions Workshop, Innsbruck, Austria.

[24] OWLAPI: A Java API for OWL. Disponível em: http://owlapi.sourceforge.net/ Acesso em: 10 de jul. de 2009.

[25] Lóscio B. F. XML: Conceitos e Aplicações. Escola Regional de Computação Ceará - Maranhão – Piaui. 2007. Ceará, Brasil.