4. Web Semântica

Em 2001, Tim Berners-Lee, James Hendler e Ora Lassila publicaram um artigo [9] na revista Scientific American onde lançam as bases da Web Semântica. Nos capítulos anteriores deste guia vimos como a Web de Documentos evoluiu para uma Web Programável, e a crescente oferta de aplicações que executam tarefas que manipulam dados publicados das mais diversas formas nesse ecossistema de dados na Web. A ideia de agregar semântica a esses dados visa a facilitar o entendimento e a interoperabilidade dos dados nesse universo de informações heterogêneas, publicadas nos mais diferentes formatos e com diferentes protocolos de acesso.

Os blocos básicos que definem a Web Semântica são:

• um modelo de dados padrão;

• um conjunto de vocabulários de referência;

• um protocolo padrão de consulta.

A Web Semântica busca facilitar o processo de comunicação entre os diversos participantes do ecossistema, de forma a criar um modelo mental comum, minimizando a possibilidade de ambiguidades, e facilitando, assim, o trabalho necessário para o desenvolvimento de aplicações que manipulem as diversas fontes de dados.

As seções a seguir têm como objetivo apresentar um panorama geral das diferentes tecnologias utilizadas no ambiente da Web Semântica, e suas características em termos de conceitos e o papel de cada uma delas no ecossistema de dados publicados na Web. O objetivo dessas seções não é o detalhamento de cada uma dessas tecnologias, que têm especificações bem definidas e uma série de materiais que as descrevem de uma maneira formal (referenciadas com links neste guia).

4.1 RDF

A Web, originalmente construída para o consumo humano, fornece uma infraestrutura simples e universal para a troca de diversos tipos de informações. Entretanto, existe uma grande dificuldade para que aplicações processem os dados expostos nos documentos sem que seja agregada uma informação específica, codificada em um formato adequado. A solução proposta é usar metadados para descrever os dados publicados na Web, que ajudem a localizar e a processar informações, fornecendo descrições sobre a estrutura, o conteúdo e outras informações relacionadas (licença de uso, direitos de propriedade intelectual, proveniência, etc.). Para isso, é necessário que se tenha uma base para o processamento dos metadados, de forma a permitir a interoperabilidade dessas descrições entre diferentes aplicações, apoiadas em padrões sobre a sintaxe e a semântica dos metadados, além de um conjunto de vocabulários comuns e formas de acesso padronizadas.

1. Modelo de Dados

Resources Description Framework (RDF) [10] é um arcabouço para representar informações na Web. RDF permite fazer afirmações sobre recursos. Recursos são quaisquer coisas, tanto concretas quanto abstratas. Uma determinada empresa, uma pessoa, uma página Web são considerados recursos. Um sentimento, uma cor, também são recursos.

O formato das afirmações é simples. Uma afirmação RDF consiste de três elementos (uma tripla) e tem a seguinte estrutura: <sujeito> <predicado> <objeto>. Uma afirmação RDF expressa uma relação entre dois recursos. O sujeito e o objeto representam os dois recursos sendo relacionados; o predicado representa a natureza desta relação, que é formulada de modo direcional (do sujeito para o objeto) e é chamada em RDF de propriedade. Um objeto pode também ser um literal, definindo uma propriedade para um recurso.

Como forma de ilustrar a ideia da definição dos dados por meio de um conjunto de triplas, vamos fazer uso de um modelo de dados conhecido: o modelo relacional e o seu conjunto de tabelas relacionadas [11]. Vamos supor uma tabela onde existam informações sobre livros (figura 4.1). Cada linha da tabela tem informações sobre um determinado livro (figura 4.2). Cada um desses livros é um recurso. Cada coluna da tabela define um tipo de propriedade relacionada aos livros (figura 4.3). Cada célula da tabela define uma tripla (figura 4.4).

A tabela contém as informações dos recursos do tipo livro:

As linhas representam os recursos:

As colunas representam as propriedades dos recursos:

Cada célula da tabela define uma propriedade (coluna) de um recurso (linha).

Uma tripla pode ser representada como uma espécie de grafo dirigido (um grafo RDF), do sujeito para o objeto:

Generalizando, temos:

A figura 4.8 apresenta o grafo RDF das triplas correspondentes a três propriedades de um mesmo recurso da tabela da figura 4.7:

No caso das triplas acima, todas elas têm um valor literal. Mas um recurso também pode estabelecer uma relação com outro recurso, o que em um esquema de tabelas relacionais seria representado por uma outra tabela, e o uso de chaves estrangeiras. No nosso exemplo, poderíamos ter uma tabela de editoras (publicadores) (figura 4.9).

A figura 4.10 apresenta o grafo RDF considerando a relação de um livro com o seu publicador.

A figura 4.11 apresenta o grafo RDF considerando dois livros do mesmo publicador.

2. URIs

Para completar esse modelo de dados, precisamos ter uma maneira de identificar cada um dos recursos e cada uma das propriedades de forma única e universal, de modo a ter uma semântica global e não apenas particular, algo que seja compreendido não apenas dentro de uma empresa ou organização. O criador de uma tabela, dentro de uma determinada organização, atribui nomes às propriedades de forma particular, como por exemplo, a propriedade “título”. Ela poderia ter sido definida como “ title ”, “nome”, “nome da obra”, “ttl”, etc. A princípio, cada organização saberia entender o significado da propriedade a partir de alguma documentação interna da empresa, norma de nomenclatura, cultura de uso dentro da empresa, etc. Mesmo assim, sabemos que muitas vezes isso não ocorre, e pode haver uma ambiguidade nesse significado. Da mesma forma, se considerarmos cada um dos recursos, muitas vezes eles são identificados por meio de identificadores que são únicos, chaves primárias, mas tem o escopo apenas dentro da tabela onde estão inseridos, e dentro do banco de dados no qual estão armazenados. Um mesmo id, por exemplo, “1243”, pode ser utilizado para identificar um publicador em uma tabela, e uma livraria em outra tabela. Eles não são identificadores únicos em termos universais. Eles são identificadores individuais dentro das tabelas de um determinado banco de dados. E mesmo quando, eventualmente sejam únicos em diversas tabelas de uma organização, eles têm que ser únicos considerando todo e qualquer recurso definido por qualquer entidade, e não somente dentro de uma determinada empresa.

Em RDF a forma de identificar tanto os recursos quanto as propriedades, de forma única e universal, se faz por meio da utilização de URIs, mais especificamente, HTTP URIs [12]. URIs são uma forma mais abrangente de URL, pois não estão necessariamente ligadas à localização do recurso. Elas têm o mesmo formato de uma URL, mas são utilizadas com o intuito de identificar as coisas, enquanto uma URL identifica um endereço para a recuperação de uma informação, um documento. Uma pessoa, por exemplo, pode ser identificada por uma URI ( figura 4.12 ).

Para se ter uma semântica mais conhecida das propriedades podemos utilizar vocabulários de referência, para a definição de propriedades de domínios específicos. Veremos alguns desses vocabulários no capítulo 6. Como exemplo, podemos citar a propriedade “nome”, que em geral é definida a partir de uma propriedade do vocabulário FOAF [13], utilizado para a definição de propriedades sobre pessoas. A URI “http://xmlns.com/foaf/0.1/name” identifica a propriedade “nome” (figura 4.13).

Uma questão muito importante quando da publicação de dados está relacionada ao esquema de identificação dos recursos, o esquema de URIs. Essa é uma discussão em curso no ambiente dos pesquisadores e publicadores de dados na Web Semântica. Existem diversos artigos que têm orientações quanto a esquemas propícios para a definição de URIs. Alguns defendem que a identificação de uma URI deve ser totalmente opaca, ou seja, não deve haver nenhuma informação na URI que possa ser interpretada em relação ao recurso que ela identifica, algo semelhante a uma chave numérica primária de uma tabela relacional. No exemplo de pessoa da figura 4.7 , temos de alguma forma essa ideia. Outros defendem que certos esquemas podem especificar algumas informações nas URIs, de forma a fazer com que um usuário possa intuir uma outra URI relacionada, sem que seja necessário recorrer a alguma outra forma de busca. Por exemplo, uma URI com informações sobre o orçamento federal pode conter na sua formação o ano relativo às informações que se deseja: “http://orcamento.dados.gov.br/doc/2013/ItemDespesa”. Caso o usuário queira as informações sobre um outro ano, basta substituir o ano na URI.

Um outro cuidado importante que se deve ter quando se define um esquema de nomeação de URIs é garantir que esse esquema seja persistente, ou, pelo menos, dure o máximo de tempo possível. E, caso alguma URI se torne obsoleta, prover uma maneira de informar ao usuário esse fato e como seria possível recuperar essa informação, às vezes disponível em algum outro local identificado por uma outra URI. Existem diversos esquemas que buscam garantir a persistência das URIs, entre eles o DOI System [14] e o PersId Initiative [15].

Essa discussão é bastante abrangente e não está no escopo deste guia esgotar esse assunto. Caso o leitor queira mais informações, os seguintes artigos, entre outros, trazem dados importantes para a decisão quanto ao esquema de definição de URIs: “ Cool URIs for the Semantic Web ” [16], “ Cool URIs don't change ” [17].

3. Serializações

RDF é um modelo de dados abstrato, não importando como ele seja representado, desde que a representação permaneça fiel às suas propriedades abstratas. Existem diversas representações sintáticas para o modelo RDF, algumas mais adequadas para o processamento de máquina, outras mais legíveis para as pessoas.

Entre as notações mais utilizadas podemos citar RDF/XML [18], Turtle [19], N-Triples [20] e JSON-LD [21]. A primeira notação a ser utilizada foi RDF/XML, padronizada pelo W3C, e seu uso inicial tinha como vantagem o fato de as linguagens de programação terem mais suporte para XML. Além disso, também é possível fazer uso de namespaces XML para evitar o uso de URIs completas, o que torna as URIs menos extensas. Porém, a leitura da codificação em RDF/XML é bastante difícil para humanos.

Nesta seção, como forma de ilustrar as serializações, será apresentada uma descrição geral da notação Turtle ( Terse RDF Triple Language ), que é de mais fácil leitura para as pessoas. A partir do seu entendimento, é possível compreender a ideia das serializações. Os detalhes da sintaxe de cada uma das notações estão descritos nas referências de cada uma das especificações. Para o entendimento das outras notações basta compreender a sintaxe específica de cada uma, pois os conceitos abstratos de todas elas são os mesmos: os conceitos do modelo de dados RDF. Além disso, também será apresentada uma descrição geral de JSON-LD, que tem tido uma grande aceitação na comunidade de desenvolvedores de software.

No exemplo de Turtle, será utilizado o grafo RDF da figura 4.8 . Além do vocabulário FOAF, citado anteriormente, utilizaremos três propriedades do vocabulário Dublin Core [22], para descrever o isbn ( International Standard Book Number ), o criador da obra, e para relacionar a obra com o publicador.

A sintaxe Turtle é formada por sentenças com os três elementos que definem uma afirmação em RDF. Essas sentenças são finalizadas pelo sinal de pontuação “.”. A figura 4.14 apresenta as quatro triplas da obra “Gabriela, Cravo e Canela” representadas em Turtle.

Como forma de tornar menos extensa a descrição em Turtle, é possível agrupar definições de múltiplas propriedades de um mesmo recurso, informado a URI do recurso uma única vez e utilizando um sinal “;” entre as diversas definições de propriedades (figura 4.15).

Como forma de tornar ainda mais legível a definição das triplas, é possível definir um conjunto de prefixos, que são correspondentes aos namespaces dos vocabulários utilizados (figura 4.16).

A figura 4.17 apresenta a serialização em Turtle do grafo da figura 4.11.

Uma serialização de RDF que tem tido um crescente uso na Web Semântica é JSON-LD (Javascript Object Notation for Linked Data ), um formato de serialização de triplas RDF que tem como objetivo ser uma forma de representação mais legível para as pessoas, utilizando o modelo JSON de conjuntos de pares atributo-valor para representar o conjunto de triplas.

Um do elementos centrais de JSON-LD é a ideia de contexto. Quando duas pessoas se comunicam em um ambiente compartilhado, existe um contexto de conhecimento mútuo que permite que os indivíduos usem termos abreviados, um vocabulário próprio, para se comunicar mais rapidamente, mas sem perder a precisão. Um contexto em JSON-LD funciona da mesma forma. Ele permite que duas aplicações usem termos abreviados, termos particulares, para se comunicar com mais eficiência, mas sem perder a precisão. Essa foi uma necessidade percebida pelos desenvolvedores da especificação de JSON-LD (uma recomendação do W3C), resultante da dificuldade de entendimento das longas URIs que representam os recursos RDF. De uma certa forma é um retorno a um vocabulário mais simplificado, mais particular, compartilhado por uma comunidade de um determinado domínio de aplicações.

As figuras 4.18 a 4.21 ⁴ ilustram a passagem de uma representação de três pares de atributos-valor em JSON, sem uma referência semântica universal, até a especificação de um código JSON-LD, onde os mesmos três pares têm associados a si um contexto que define a semântica universal dos termos.

A figura 4.18 apresenta três propriedades de uma pessoa, em formato JSON:

• “name” – nome (literal)

• “homepage” – página pessoal (URL)

• “image” – imagem (URL)

A figura 4.19 substitui os termos (do vocabulário particular da comunidade) pelas URIs das propriedades dos vocabulários de referência. Por exemplo, “name” é substituído pela URI “http://schema.org/name”. Além disso, é informado se o valor da propriedade do atributo é um outro recurso (@id). A introdução das URIs torna o texto menos legível.

A figura 4.20 apresenta a definição de um contexto onde os nomes abreviados da figura 4.18 são associados às URIs introduzidas na figura 4.19. A associação das abreviações com as definições semânticas universais (contexto), ficam separada das definições dos pares atributo-valor. Isso permite que as abreviações voltem a ser utilizadas. O contexto funciona como um mapeamento entre o vocabulário particular e o vocabulário de referência.

Os contextos podem ser definidos em conjunto com os pares atributo-valor ou podem ser referenciados por URIs. Dessa forma, um determinado contexto conhecido de uma comunidade pode ser informado no início da definição dos dados e o vocabulário abreviado pode ser utilizado. O contexto da figura 4.20 poderia ser considerado como o contexto da definição de uma pessoa. A figura 4.21 ilustra como o código usaria as abreviações incluindo uma referência a um contexto definido externamente.

4.2 RDFS

O modelo de dados RDF fornece uma maneira de fazer afirmações sobre recursos, mas não faz suposições sobre a semântica dos recursos identificados pelas URIs. Não existe nenhum construtor em RDF que especifique que um recurso seja uma propriedade, ou seja um livro, uma pessoa, etc. Na prática, RDF é normalmente usado em combinação com vocabulários que fornecem informações semânticas sobre esses recursos.

Resource Description Framework Schema (RDFS) [23] é um vocabulário que estende RDF e introduz uma camada que especifica algumas características que agregam semântica a dados definidos em RDF. RDFS tem construtores que permitem, por exemplo, especificar que determinadas URIs indicam propriedades de recursos, ou que determinados recursos identificados por URIs pertencem a uma determinada classe. Utilizando o exemplo da figura 4.13, por meio do RDFS é possível especificar que o recurso identificado pela URI “http://xmlns.com/foaf/0.1/name” é uma propriedade. Ou que o recurso identificado pela URI “http://example.org/#gabriela-cravo-canela” pertence à classe “Livro”.

RDFS usa a noção de classe para especificar categorias que podem ser usadas para classificar os recursos. A relação entre uma instância e sua classe é indicada através da propriedade “ type ” de RDF. Com RDFS pode-se criar hierarquias de classes e subclasses, e hierarquias de propriedades e subpropriedades. Restrições de tipos podem ser definidas sobre os sujeitos e os objetos das triplas, por meio da especificação de domínios e contradomínios para cada um dos tipos. No exemplo anterior dos livros, poderíamos declarar que o domínio da relação “tem_publicador” é do tipo “Livro” e que o contradomínio é do tipo “Publicador”.

É muito importante ressaltar que a ideia de tipos, domínios e contradomínios de uma propriedade são diferentes daqueles do modelo orientado a objetos (OO). No modelo OO, uma classe abstrai as propriedades e os métodos de um determinado conjunto de instâncias. Se um objeto é declarado como sendo de um determinado tipo (uma classe), é assumido que ele possui um conjunto de propriedades que são associadas àquele tipo. No caso do RDFS, a declaração de uma propriedade não restringe o seu uso por qualquer recurso, qualquer que seja o seu tipo. A declaração de propriedades é feita de forma separada e independente das declarações de classes. A declaração de um domínio e um contradomínio permite apenas que se faça uma inferência de um possível tipo de um recurso, mesmo que esse tipo não esteja declarado explicitamente por meio de uma tripla. No dia a dia, os humanos fazem isso constantemente. A partir de certas propriedades observadas de objetos, pessoas, etc., os humanos inferem os tipos aos quais esses recursos podem pertencer. É uma forma comum de inferência para seres humanos..

Voltando ao RDFS, no exemplo dos livros, vamos supor que sejam declaradas as classes “Livro” e “Publicador” e que o domínio da relação “tem_publicador” é de recursos da classe “Livro” e que o contradomínio é de recursos da classe “Publicador”. Mesmo que não se declare uma tripla onde se afirme explicitamente que o recurso “http://example.org/#gabriela-cravo-canela” é da classe “Livro” e que o recurso “http://example.org/#companhia-das-letras” é da classe “Publicador”, se for declarado que existe uma relação “tem_publicador” entre esses dois recursos, as classes dos recursos serão inferidas pela declaração do domínio e do contradomínio da propriedade. Dessa forma é possível se concluir mais triplas dos que as efetivamente declaradas.

A inferência é uma das características introduzidas pelo uso das tecnologias da Web Semântica. Inferências permitem que se façam declarações menos extensas das informações. Por exemplo, em um conjunto de triplas sobre pessoas, não é necessário que se declare explicitamente as triplas com as relações do tipo “tio”, que podem ser inferidas a partir de outras relações. RDFS introduz alguns poucos tipos de inferências, que são expandidas de forma mais ampla pelo uso de OWL, como será visto na seção 4.3.

Um outro tipo de inferência introduzido por RDFS é relativo à declaração de subclasses e de subpropriedades. Se um determinado recurso é do tipo de uma determinada subclasse, será inferido que esse recurso também é do tipo da classe correspondente. O mesmo se dá em relação às subpropriedades.

A figura 4.22 ilustra a introdução de alguns construtores de RDFS no exemplo da figura 4.17. Para a definição da classe “Livro”, utilizamos a ontologia “ bibo ” [24], relativa à definição de informações bibliográficas. A palavra-chave “a” é uma abreviação para o predicado “rdf:type”, que indica a classe de um recurso.

4.3 OWL

RDF especifica um modelo de dados que representa informações por meio de um conjunto de triplas que definem propriedades de recursos, e relacionamentos entre esses diversos recursos. RDFS estende RDF possibilitando a definição de hierarquias de classes, hierarquias de propriedades e a definição de domínios e contradomínios para as propriedades, permitindo assim um primeiro conjunto de restrições sobre as triplas definidas, além de inferências que deduzem triplas não declaradas de forma explícita.

Por que definir restrições? Uma das formas de se entender o que é semântica é pensar que o que faz com que diferentes pessoas possam entender o mesmo significado de algum conteúdo é restringir o número de diferentes interpretações possíveis sobre aquele conteúdo. O ideal seria que houvesse apenas uma interpretação possível.

Ontology Web Language [25] é uma linguagem que estende RDF e RDFS e oferece um conjunto muito mais amplo de tipos de restrições ao conjunto de triplas definidas. Além disso, são oferecidos diversos construtores que permitem, entre outros, a construção de classes complexas a partir de outras definições de classes, e encadeamento de propriedades. Uma das principais bases do OWL é Description Logics (DLs) [26], uma família de linguagens de representação de conhecimento amplamente utilizadas na modelagem de ontologias. Uma ontologia é uma especificação de um conceito dentro de um determinado domínio de interesse. Como seu nome sugere, DLs são lógicas e possuem uma semântica formal: uma especificação precisa do significado. Esta semântica formal permite que os seres humanos e sistemas de computador possam intercambiar ontologias DL sem ambiguidade quanto ao seu significado, e também torna possível usar dedução lógica para inferir informações adicionais dos fatos expostos explicitamente em uma ontologia.

Ontologias fornecem meios para modelar as relações entre as entidades em um domínio de interesse. Em OWL existem três tipos de entidades

• Instâncias – representam os recursos (são também chamados de indivíduos).

• Classes – definem conjuntos de instâncias, de indivíduos.

• Propriedades – representam relações binárias entre duas instâncias ( object property ) ou entre uma instância e um literal ( datatype property ).

Uma ontologia especificada em OWL consiste de um conjunto de afirmações (axiomas), separadas em três grupos: Tbox ( Terminological ), Abox ( Assertion ) e Rbox ( Role ).

A Tbox descreve relacionamentos entre classes. Por exemplo, a afirmação que a classe “ Person ” é equivalente a classe “ Human ” significa que as duas classes possuem o mesmo conjunto de indivíduos. A Abox captura conhecimento sobre os indivíduos, ou seja, as classes as quais eles pertencem e como eles se relacionam entre si. Por exemplo, podemos fazer uma afirmação que o indivíduo “ Mary ” é da classe “ Person ”, isto é, “ Mary ” é uma instância da classe “ Person ”. Se juntarmos com o exemplo, da Tbox , em que a classe “ Person ” é definida como equivalente à classe “ Human ”, pode-se inferir que “Mary” também é uma instância da classe “ Human ”:

Na Tbox também são definidos relacionamentos entre os indivíduos. Por exemplo, podemos definir que “Mary” é esposa de “John”:

A Rbox contém as afirmações sobre as propriedades, ou seja, metapropriedades como, por exemplo, transitividade, simetria, etc. Essas afirmações podem permitir que inferências sejam feitas sobre a base de triplas definidas explicitamente:

Os itens a seguir oferecem um resumo dos diversos construtores contidos na especificação da linguagem OWL:

• Classes são definidas em RDFS por meio da propriedade “type” de RDF:

• A classe de uma determinada instância pode ser declarada explicitamente, ou pode ser inferida como, por exemplo, a partir da definição de subclasses ou de domínio e contradomínio:

• É possível definir que dois nomes de indivíduos representam o mesmo indivíduo, ou seja, o grafo RDF do recurso será o somatório das afirmações sobre cada um dos indivíduos:

• Classes equivalentes possuem o mesmo conjunto de instâncias:

• Classes disjuntas indicam que uma instância que pertença a uma delas não pertence a outra.

• Uma propriedade pode ter uma valor literal ( datatype property ) ou estabelecer um relacionamento entre duas instâncias ( object property ).

• Classes complexas podem ser construídas a partir de outras classes, por meio de interseção, união, complemento e enumeração:

• Propriedades podem ter uma cardinalidade que indica o número (máximo, mínimo ou exato) de triplas:

• Propriedades podem ser transitivas :

• Propriedades podem ser inversas:

• Propriedades podem ser simétricas (a inversa da propriedade é a mesma propriedade, por exemplo, cônjuge):

• Propriedades podem ser assimétricas (a propriedade inversa não pode ser a mesma propriedade, por exemplo, uma pessoa não pode ser filha do seu filho):

• Propriedades podem ser definidas como encadeamentos de outras propriedades (avô é o pai do pai):

• Propriedades podem ser reflexivas (uma pessoa é parente de si própria):

• Propriedades podem ser irreflexivas (uma pessoa não pode ser pai de si mesma):

• Propriedades podem ser funcionais (só existe um elemento no contradomínio para um elemento do domínio, por exemplo, mãe):

• Propriedades podem ser inversamente funcionais (só existe um elemento no domínio para um elemento do contradomínio, por exemplo, filho):

4.4 SPARQL

Os dados são representados na Web Semântica utilizando o modelo de dados conceitual de RDF, em conjunto com as extensões de RDFS e OWL. Esses dados podem estar armazenados em, por exemplo, um banco de dados de triplas ( triple store ), um banco de dados relacional com um esquema de mapeamento para rdf, etc.

SPARQL ( SPARQL Protocol and Query Language ) [27] é a linguagem de consulta da Web Semântica. Podemos fazer uma analogia entre SPARQL e a linguagem SQL de consulta a bancos de dados relacionais, considerando que SPARQL tem uma sintaxe adequada a consultas a dados representados como um conjunto de triplas RDF.

Por exemplo, considere um banco de triplas com o seguinte conteúdo:

A consulta

retornaria:

As variáveis SPARQL começam com um caractere “?” e podem ser definidas em qualquer uma das três posições de uma tripla (sujeito, predicado, objeto) no conjunto de dados RDF. Os padrões de triplas da cláusula SELECT têm a mesma forma de triplas normais, exceto que qualquer uma das três partes da tripla pode ser substituída por uma variável. A cláusula SELECT retorna uma tabela de variáveis com os valores que satisfazem a consulta.

Em um outro exemplo, considere um banco de triplas com o seguinte conteúdo:

A consulta:

retornaria:

SPARQL admite uma série de filtros e operadores que permitem fazer consultas complexas ao conjunto de triplas armazenadas. Diversos bancos de dados de triplas oferecem pontos de acesso via Web (URLs), que aceitam o protocolo SPARQL e sua linguagem de consulta. Esses pontos de acesso são denominados SPARQL endpoints . Um SPARQL endpoint aceita consultas e retorna os resultados via HTTP. Endpoints genéricos executam consultas em qualquer dado RDF com acesso possível pela Web (especificado como parâmetro) . Endpoints específicos executam consultas apenas em conjuntos de dados particulares, fixados pela aplicação . As listas de alguns SPARQL endpoints existentes na Web são apresentadas em SPARQLES [28], W3C SPARQL endpoints [29] e Mondeca [30] . Um e ndpoint genérico é oferecido por Openlink [31], onde é possível fazer consultas a partir da especificação da localização do grafo RDF que contém o conjunto de triplas a ser inspecionado.

A cláusula SELECT aceita que seja especificado o grafo RDF que será consultado, por meio da utilização da palavra-chave FROM. No exemplo a seguir (figuras 4.23 e 4.24), são retornadas as homepages das pessoas conhecidas (“foaf:knows”) por Tim Berners-Lee, no grafo RDF localizado em http://dig.csail.mit.edu/2008/webdav/timbl/foaf.rdf

As consultas SPARQL não retornam conjuntos de triplas. O resultado é um conjunto de tuplas (como linhas de uma tabela), que pode vir em diferentes formatos como, por exemplo, HTML, XML, JSON, CSV, etc. Esse formato é especificado como um dos parâmetros da consulta. A figura 4.25 apresenta o resultado em JSON da consulta anterior:

Além do comando SELECT, SPARQL aceita os comandos DESCRIBE, CONSTRUCT e ASK. O comando DESCRIBE retorna um grafo RDF simples contendo os dados RDF sobre os recursos especificados no comando. Os dados retornados são determinados pelo processador de consulta SPARQL e não pelo cliente que fez a consulta. Podem ser retornadas triplas onde o recurso aparece como sujeito, predicado ou objeto, triplas onde o recurso aparece como sujeito ou objeto, ou triplas onde o recurso aparece apenas como sujeito.

O acesso às triplas de um recurso também pode ser feito por meio de uma dereferenciação (a partir da definição de uma URI), que é um dos princípios de Dados Conectados na Web (seção 5.1). O resultado de uma dereferenciação, assim como o resultado de um comando DESCRIBE, retorna um conjunto de triplas de recursos. O site DBpedia contém triplas extraídas das caixas de informações de artigos da Wikipedia. A dereferenciação da URI da DBpedia que identifica Tim Berners-Lee pode ser visualizada em http://dbpedia.org/page/Tim_Berners-Lee [32]. Essa página é retornada originalmente em HTML mas é possível obter o seu resultado em outros formatos, como por exemplo, em JSON [33].

A figura 4.26 apresenta um exemplo de comando DESCRIBE em uma consulta no endpoint da DBpedia [34] . A figura 4.27 apresenta parte dos resultados. É possível observar que são listadas triplas onde o recurso (“ :Tim_Berners-Lee” ) aparece como sujeito e como objeto.

De forma análoga à SQL, existe a possibilidade de manipular o conjunto de resultados retornados por uma consulta SPARQL:

• LIMIT – limita o número de linhas.

• DISTINCT – remove linhas duplicadas.

• ORDER – ordena o resultado.

• OFFSET – permite paginação.

• FILTER – aplica filtros sobre os valores procurados nas propriedades.

SPARQL oferece, também, uma série de funções pré-construídas utilizadas na especificação das consultas, que incluem operadores lógicos (“!”, “&&”, “||” ), operadores matemáticos (“+”, “-”, “*”, “/”), operadores comparativos (“=,” “>”, “<”, ...), operadores de teste (“isLiteral”, isURI”, ...), funções de manipulação de cadeias de caracteres (“STRLEN”, “SUBSTR”, “UCASE”, “CONCAT”, ...), etc.

CONSTRUCT é um comando da linguagem SPARQL, que permite que a partir de um resultado de pesquisa seja construído um conjunto de triplas. A figura 4.28 apresenta um exemplo de comando CONSTRUCT em uma consulta no endpoint da DBpedia. A figura 4.29 apresenta os resultados.

Além da especificação da linguagem de consulta em si, existem diversos outros padrões relacionados ao SPARQL, definidos pelo W3C, que especificam, por exemplo, uma linguagem para a manipulação e atualização de grafos RDF ( SPARQL 1.1 Update [35]), consultas federadas em diversos grafos RDF ( SPARQL 1.1 Federated Query [36]), etc.

4.5 Metadados Embutidos em Páginas

Nas seções anteriores apresentamos o modelo de dados conceitual do RDF, com seu conjunto de triplas de recursos identificados por URIs, além da apresentação de extensões por meio de RDFS e OWL, que permitem a construção de ontologias mais complexas, com um maior número de restrições e possibilidades de inferências. Apresentamos, também, a linguagem SPARQL para consulta a grafos RDF.

Essas tecnologias estão mais direcionadas para grafos que estão armazenados nos servidores Web. Existe, porém, um universo de dados sendo descritos semanticamente, espalhados em páginas HTML, que contêm uma mescla do conteúdo a ser consumido pelas pessoas com o conteúdo a ser consumido pelas aplicações. Existe uma crescente inclusão de dados semânticos nessas páginas, por criadores de páginas interessados em atender às demandas das aplicações. A inclusão de dados semânticos em um site de vendas, por exemplo, pode auxiliar a máquina de busca da Google a expor de forma mais precisa e objetiva os resultados da procura por um determinado produto.

A seção 2.5 sobre metadados, apresentou a forma inicial de introdução de metadados em uma página Web, por meio do tag <meta> de HTML. Esses metadados são relacionados à página Web, como um todo. Eles podem, por exemplo, prover informações sobre o autor da página, palavras-chave, descrição, data de publicação, etc. Nas seções seguintes apresentaremos três formatos utilizados para a inclusão de metadados em páginas Web, que podem ser aplicados, também, na descrição individual dos dados contidos nas páginas.

O objetivo dessas seções é descrever de forma sucinta essas três técnicas de embutir dados em páginas da Web. O importante é compreender que essa é uma das formas de se definir metadados para a construção de uma Web de Dados mais semântica, complementar ao que foi apresentado nas seções anteriores.

4.5.1 Microformato

O microformato [37] foi a primeira iniciativa no sentido de agregar informações extras ao código HTML, de forma que fosse possível incluir tipos específicos de dados (entidades), como por exemplo, pessoas, produtos, eventos, etc. Cada um desses tipos possui um conjunto particular de propriedades e uma sintaxe específica. Por exemplo, uma pessoa pode ter as propriedades nome, endereço, empresa, função, e-mail, etc.

A interpretação de um código HTML, para fins de exibição de dados para o usuário, ignora qualquer tag desconhecido da especificação HTML. Em geral, microformatos utilizam os atributos de classe em tags HTML (frequentemente <span> ou <div>) para atribuir nomes para entidades e suas propriedades.

O exemplo das figuras 4.30 e 4.31 ilustra como mesclar informações que serão filtradas pelo navegador para a exibição da página e informações que serão filtradas pelas aplicações para o entendimento do conteúdo.

A seguir são apresentadas algumas das propriedades que podem ser definidas para uma entidade do tipo pessoa :

• fn – nome completo. obrigatório

• n – nome estruturado:

• given-name – primeiro nome

• additional-name – nome do meio

• family-name – sobrenome

• title – função

• org – companhia, organização

• photo – foto, ícone, avatar

• email – e-mail

• tel – telefone

• adr – endereço estruturado:

• street-address – rua

• locality – cidade

• region – estado

• postal-code – código postal

• country-name – país

Cada microformato específico tem um conjunto particular de propriedades (vocabulário). Microformatos são fáceis de utilizar devido a sua simplicidade, mas oferecem pouca capacidade de extensão, não tendo uma forma padrão de representação para os vocabulários. Além disso, só é possível especificar metadados para um pequeno conjunto de tipos de dados. Microformatos2 [38] busca evoluir o conceito de microformatos e criar uma sintaxe comum independente de vocabulários e uma padronização maior na nomenclatura das entidades e das propriedades.

4.5.2 RDFa

Assim como microdados, RDFa [39] permite que metadados sejam embutidos em páginas Web, mas utiliza uma sintaxe mais genérica para especificar as triplas RDF, independente do tipo de dados ao qual o recurso pertence e do vocabulário utilizado. As informações das triplas são especificadas na forma de atributos dentro dos tags do HTML:

• vocab – URI do vocabulário ( namespace )

• about, src, href e resource – URI do recurso

• typeof – tipo do recurso

• rel – relação com outro recurso

• rev – relação inversa com outro recurso

• property – nome da propriedade (o valor da propriedade é o texto que aparece entre os tags onde é definido o atributo)

• content – substitui o valor da propriedade que aparece entre os tags onde é definido o atributo

• datatype – tipo do dado da propriedade

Como forma de ilustrar alguns desses atributos, serão apresentados dois exemplos (com suas figuras) extraídos da especificação RDFa [40] do W3C. Na Figura 4.32 são definidas triplas referentes a dois recursos. As figuras 4.33 e 4.34 ⁵ apresentam os grafos RDF dessas triplas e ajudam a entender a forma como elas são definidas por meio do RDFa embutido no código HTML.

O exemplo da Figura 4.35 apresenta o uso do atributo “rel”, que define uma relação entre dois recursos, no caso, a relação “foaf:knows” (alguém conhecido de uma determinada pessoa). No exemplo, os recursos que são objetos dessas triplas são do tipo “foaf:Person” e para cada um deles é definido um “foaf:name” e uma “foaf:homepage”. O que o navegador exibirá para o usuário serão os links para as homepages de Bob, Eve e Ana.

4.5.3 Microdados

Microdados [41] são uma forma mais recente de embutir metadados em páginas Web. Ela tem tido uma crescente utilização, sendo uma das formas preferenciais das máquinas de busca como, por exemplo, a Google. Apesar de poder utilizar qualquer vocabulário para a definição de seus recursos, os criadores de páginas que utilizam microdados fazem muito uso do conjunto de vocabulários definidos pela iniciativa Schema.org (seção 6.4).

Da mesma forma que RDFa, a sintaxe de microdados não depende dos tipos de dados dos recursos definidos, nem do vocabulário utilizado para a sua descrição. A forma de embutir as informações também é por meio da definição de atributos nos tags HTML. O modelo de microdados consiste em grupos de pares nome-valor, conhecidos como itens. Cada item pode ter um tipo, um identificador global e uma lista de pares nome-valor. Cada nome do par nome-valor é conhecido como uma propriedade, e cada propriedade tem um ou mais valores. Cada valor é um item ou um literal. Os atributos básicos de microdados são:

• itemscope – define o recurso

• itemid – define uma URI para o recurso

• itemtype – define o tipo do recurso (vocabulário)

• itemprop – define uma propriedade do recurso

A figura 4.36 apresenta um exemplo de microdados para uma pessoa, utilizando o tipo de dados “ Person ” [42] do Schema.org, que tem uma série de propriedades definidas como, por exemplo, “name”, “image’, “jobTitle”, “telephone”, “email”, “colleague”, entre outras, todas com uma semântica bem definida. No exemplo é possível perceber que a propriedade “address” pode ser uma propriedade que aponta para um outro recurso (“itemscope”), que tem um outro tipo de dados, “PostalAddress”.

Da mesma forma que em RDF, o modelo de dados de microdados em si não entra no mérito do significado de cada um dos vocabulários. A sintaxe para o seu uso como metadado é única, independente de vocabulários, e a escolha e o uso adequado de cada um deles, e de suas propriedades, requer um estudo específico por parte do usuário.

A semântica agregada aos dados é materializada pela utilização das sintaxes apresentadas (RDF, RDFS, OWL, microformatos, RDFa, microdados) em conjunto com ontologias próprias, desenvolvidas para casos específicos, e os vocabulários de referência, que se estabelecem pela cultura de uso. No capítulo 6 são apresentados exemplos de alguns dos vocabulários mais utilizados.