Predição de tags usando linked data: um estudo de caso no banco de dados Arquigrafia. Ricardo Augusto Teixeira de Souza

(1)

Predição de tags usando linked data:

um estudo de caso no

banco de dados Arquigrafia

Ricardo Augusto Teixeira de Souza

Dissertação apresentada

ao

Instituto de Matemática e Estatística

da

Universidade de São Paulo

para

obtenção do título

de

Mestre em Ciência da Computação

Programa: Ciência da Computação

Orientadora: Profa. Dra. Leliane Nunes de Barros

(2)

(3)

Resumo

A rede Linked Data é um dos principais componentes que compõe a Web Semântica. Essa rede provê uma imensa quantidade de recursos Web descritos em RDF (Resource Description Fra-mework ). Esse trabalho aplica um algoritmo de mineração de dados utilizando as medidas de similaridade taxonômica, relacional e literal, em um banco de dados sem referências a uma rede de Linked Data. Esses resultados são comparados com a aplicação desse algoritmo no mesmo banco de dados em que são feitas referências a uma rede de Linked Data. Isso é feito utilizando-se os dados do Arquigrafia, um sistema de banco de dados na Web cujo objetivo é catalogar projetos arquitetônicos, e usar esse sistema de mineração de dados para sugerir novos tags para as imagens. Os resultados mostram que o uso dos recursos disponíveis na rede Linked Data podem melhor as recomendações das tags.

Palavras-chave: Web Semântica, Linked Data, Mineração de dados, Recomendação de Tags.

(4)

(5)

Abstract

The Linked Data network is one of the main components that build the Semantic Web. This network offers a huge amount of web resources described in RDF (Resource Description Framework). This work aplies a data mining algorithm using the taxonomic, relational and literal similarities in a database without references to a Linked Data network. These results are compared with the application of this data mining algorithm in the same database where are made references to a Linked Data network. This is done using the data of the Arquigrafia website, a web application which goal is to catalog architecture projects, and by using this system suggest new tags for the images. The results shown that the use of the Linked Data resources can improve in the tag recommendation system.

Keywords: Semantic Web, Linked Data, Data Mining, Recommendation.

(6)

(7)

Sumário

1 Introdução 1

2 Web Semântica 5

2.1 Linguagens da Web Semântica . . . 6

2.1.1 XML - eXtensible Markup Language . . . 6

2.1.2 RDF - Resource Description Framework . . . 8

2.1.3 OWL - Web Ontology Language . . . 12

2.2 Linked Data . . . 12

2.2.1 Publicação e Consumo . . . 14

2.2.2 O projeto DBpedia . . . 17

3 Similaridade entre instâncias RDF 19 3.1 Definição formal de RDF . . . 19

3.2 Métrica de Similaridade entre Instâncias RDF . . . 21

4 Predição de tags usando Agrupamento Hierárquico 25 4.1 Predição de tags . . . 27

5 Avaliação e Resultados 29 5.1 Resultados . . . 31

5.1.1 Pesos iguais para as similaridades . . . 31

5.1.2 Maior peso à similaridade Literal . . . 32

5.1.3 Maior peso à similaridade Relacional . . . 32

5.1.4 Maior peso à similaridade Taxonômica . . . 33

6 Conclusão e Trabalhos Futuros 35

Referências Bibliográficas 37

(8)

(9)

Capítulo 1

Introdução

A Web contém uma imensurável quantidade de informação. Essa informação está interconectada e encontra-se distribuída em forma de páginas, imagens, vídeos, documentos, entre outros. Em outras palavras, a Web pode ser comparada a um enorme grafo, em que os nós deste grafo representam os documentos, páginas e imagens, e os arcos representam os links entre eles. A forma dinâmica com que são adicionados novos arcos e nós a esse grafo caracteriza a Web como uma grande rede de informação desestruturada. Logo, compartilhar e recuperar determinada informação pode ser difícil [Xu et al., 2006].

Páginas, imagens, vídeos são exemplos do que é denominado um recurso Web. Um recurso é, por definição, qualquer entidade que tenha uma identificação [Breitman et al., 2007]. Um recurso pode ser uma entidade digital (tais como documentos, imagens eletrônicas etc.) [Koivunen e Miller, 2001], uma entidade física (por exemplo, um livro identificado pelo seu ISBN), ou ainda uma coleção de outros recursos [Breitman et al., 2007]. No caso de um recurso Web, sua identificação é a URI (Uniform Resource Identification), que é uma sequência de caracteres que tem por função identificar um recurso na Web através de um endereço eletrônico [Breitman et al., 2007].

Numa tentativa de estruturar a informação na Web, os recursos podem ser descritos através de um conjunto de propriedades e seus valores, definidos de acordo com um vocabulário controlado. Por vocabulário controlado entende-se um conjunto restrito e previamente conhecido de termos definidos pelo projetista de um sistema Web. Como, por exemplo, um banco de dados na Web, isto é, feito para ser consultado por um usuário Web.

O objetivo de estruturar a informação da Web é facilitar a sua recuperação no futuro. Com os recursos descritos segundo um vocabulário controlado, é trivial realizar uma busca por registros de um bando de dados. Por exemplo, dado um conjunto de recursos que descrevem pessoas cujo vocabulário define as propriedades “nome”, “idade”, “sexo” e “e-mail”, é possível buscar pelas pessoas com idade maior que 18, ou pelos e-mails das pessoas com propriedade sexo igual a masculino, e assim por diante.

Tabela 1.1: Propriedades definidas no vocabulário Arquigrafia cujas valores referem-se à imagem do Palácio Gustavo Capanema (Figura 1.1)

Propriedade Valor

Nome: Palácio Gustavo Capanema (Ministério da Educação e Cul-tura)

Descrição: Vista geral do Palácio Gustavo Capanema (Ministério da Educação e Cultura)

Imagem: http://www.arquigrafia.org.br/photo/img-show/1220.jpeg Autor do projeto: COSTA, Lúcio Marçal Ferreira Ribeiro de Lima e

Autor da imagem: FAU

Data da criação do projeto: 2012-07-31 08:05:31

Estado: RJ

Cidade: Rio de Janeiro Bairro: Centro

Endereço: Rua da Imprensa, 16

(10)

2 INTRODUÇÃO 1.0

Figura 1.1: Exemplo de um recurso Web do sistema Arquigrafia cujo URI é “http://www.arquigrafia.org.br/photo/1220”.

O uso de um banco de dados para armazenar as informações é usualmente associado à denomi-nada Deep Web ou Hidden Web [Hogan et al., 2011]. Deep Web refere-se à informação armazedenomi-nada em banco de dados e que só pode ser acessada através de uma interface, usualmente por uma página Web [Hogan et al., 2011]. Tal informação é dificil de ser acessada, pois seu acesso é realizado quase que unicamente através da interface programada por um especialista que conhece o esquema de armazenamento do banco de dados - caracterizando um sistema fechado. Assim, embora a informa-ção esteja estruturada segundo um vocabulário, ela está contida e isolada, e dificilmente pode ser acessada por técnicas de rastreamento.

Uma outra forma de armazenar os recursos Web é com o uso da Web Semântica. O objetivo da Web Semântica é adicionar semântica aos recursos Web. Neste contexto, semântica é a atribui-ção de descrições utilizando-se de conceitos lógicos em um determinado domínio [Russell e Norvig, 2010]. Para descrever os recursos são adotadas linguagens específicas, e as descrições, por outro lado, não são armazenados num banco de dados, permanecendo acessíveis independente de uma interface - caracterizando um sistema aberto. Dessa forma, a Web Semântica busca tornar a deep web mais acessível, contando que os recursos sejam descritos com uma linguagem descritiva padrão [Hogan et al., 2011] disponível na Web para ser amplamente compartilhada.

Há ainda uma outra forma de estruturar a Web: através da associação de tags aos recursos Web. Tags são marcações de texto simples, atribuídos a um recurso Web e que não necessariamente estão relacionados a um vocabulário controlado. Geralmente, uma tag busca descrever alguma caracterís-tica do recurso Web associado. A Figura 1.1 mostra a imagem de um edifício catalogado no sistema Arquigrafia1, que é um recurso Web cujo URI é “http://www.arquigrafia.org.br/photo/1220”. O projeto Arquigrafia tem como finalidade catalogar e descrever imagens de projetos arquitetônicos,

1

(11)

1.0 3

tais como edifícios, parques ou praças, através de um sistema Web de banco de dados. Cada imagem catalogada possui um conjunto de valores para as propriedades que as descrevem. Esses valores, chamados dedescritores originais, são dados pelo fornecedor da imagem. As propriedades definidas para descrever uma imagem no sistema Arquigrafia são exibidas na Tabela 1.1 com um exemplo de valores dados ao Palácio Gustavo Capanema (Figura 1.1). As propriedades Nome, Descrição, Imagem, Autor, Autor da Imagem, Data de criação, Estado, Cidade, Bairro, Endereço e Tags fa-zem parte de um vocabulário controlado. Seus valores são vistos como instâncias das respectivas propriedades. Note que os valores da propriedade tags (1.2) não possuem uma interpretação como, por exemplo, ministério e concreto, que são valores das propriedades Funcionalidade e Material. Assim, pode-se dizer que os valores das tags fazem parte de um vocabulário não controlado.

Tabela 1.2: Tags associadas à imagem ilustrada na Figura 1.1

Concreto, Alvenaria, Vidro, Ferro, Pilar, Público, Edifício, Prédio, Concreto aparente, Es-quadria, Pano de vidro, Poste, Janela basculante, Cimento, Pedra, Coluna, Caixilho, Ja-nela, Cerâmica, Fachada, Pilotis, Administrativo, Ministério, Montante

Tags são uma ferramenta poderosa quando utilizados para o propósito de recuperação da infor-mação. O uso de tags permite ao usuário do sistema recuperar o recurso previamente marcado por ele, além de possibilitar a descoberta de novos recursos também marcados por tags [Xu et al.]. Em geral, para que a atribuição de tags a recursos Web funcione, a suposição aceita é de que, apesar da ausência de um vocabulário, existe um senso comum por parte dos usuários na interpretação do sig-nificado de determinada tag [Aurnhammer et al., 2006]. Diversos sites na Web adotam o uso de tags para descrever recursos, tais como, por exemplo, o Flickr2 (anotações de imagens) e o Del.ico.us3 (anotações de páginas Web).

Dada a atual importância das tags na Web, o objetivo deste trabalho é a criação de um sistema que possa recomendar ou predizer tags para um novo recurso Web baseado na similaridade deste novo recurso aos demais já existentes no sistema. Por exemplo, se for adicionado ao sistema Arqui-grafia o recurso descrito na Tabela 1.3, este, por ser similar ao recurso descrito na Tabela 1.1, deve ter como resultado da predição um conjunto de tags similares às apresentadas na Tabela 1.2, tais como “concreto”, “alvenaria”, “vidro”, “ferro”, “pilar”, etc.

Tabela 1.3: Exemplo de valores atribuídos às propriedades do Arquigrafia, e similar à instância Palácio Gustavo Capanema (Figura 1.1)

Propriedade Valor

Nome: Palácio Gustavo Capanema

Descrição: Vista para a Baía de Guanabara do Palácio Gustavo Capa-nema (Ministério da Educação e Cultura)

Imagem: http://www.arquigrafia.org.br/photo/img-show/1253.jpeg Autor do projeto: Lúcio Costa

Autor da imagem: FAU

Data da criação do projeto: 2012-07-31 08:05:31 Estado: Rio de Janeiro Cidade: Rio de Janeiro

Bairro: Centro Endereço: Imprensa, 16

Mais formalmente, o problema da predição é dado a seguir: considerando um conjunto C de tuplas < r, T > onde r é o recurso e T é um conjunto de tags, a predição de tags consiste em prever o conjunto de tags T0 para um novo recurso r0 acrescentado em C [Heymann et al., 2008].

2

http://www.flickr.com

(12)

4 INTRODUÇÃO 1.0

Portanto, este trabalho teve como objetivo a construção de tal sistema, que irá atuar nos recurso do sistema Arquigrafia, incorporando ao método utilizado para a predição a tecnologia da Web Semântica. A contribuição deste trabalho é o desenvolvimento desse sistema, e ua análise do uso da Web semântica pode auxiliar na recomendação de tags dos recursos presentes no sistema Arquigrafia. A organização do texto segue o seguinte formato: o Capítulo 2 introduz a Web Semântica, as linguagens utilizadas para a descrição de recursos e o Linked Data, um dos núcleos da Web Semântica; o Capítulo 3 apresenta a métrica de similaridade usada no algoritmo de mineração de dados; o Capítulo 4 descreve o algoritmo de mineração de dados e o método utilizado para a predição de tags; o Capítulo 5 mostra e discute os resultados obtidos; e o Capítulo 6 contém as conclusões deste trabalho.

(13)

Capítulo 2

Web Semântica

Web Semântica é a atribuição de semântica à informação presente na Web. Entende-se por semântica a atribuição de descrições, utilizando-se de conceitos lógicos, a um determinado domínio [Russell e Norvig, 2010]. Na Web isso é feito através de linguagens de descrições, cada uma com diferentes níveis de expressividade.

Na prática, a Web semântica refere-se ao uso de linguagens de descrições para descrever de-terminadas informações, tornando explícito seu significado. Uma vez que a informação esteja ex-plicitamente descrita (segundo uma linguagem de descrição), é possível a aplicação de algoritmos computacionais com a finalidade de obter conclusões lógicas.

O processo de obtenção de conclusões lógicas referentes a uma informação na Web depende da expressividade da linguagem descritiva utilizada e da confiabilidade dessa descrição. A Figura 2.1 exibe as camadas de expressividade existentes na Web Semântica.

Figura 2.1: Camadas da Web Semntica [Koivunen e Miller, 2001].

Na Figura 2.1, as camadas mais baixas definem a codificação e o acesso às informações na Web. O uso da codificação Unicode possibilita o uso de caracteres internacionais na representação dos recursos [Koivunen e Miller, 2001], e o URI (Uniform Resource Identifier ), similar ao URL (Uniform Resource Locator ), permite associar um identificador único e global ao recurso. A diferença entre URL e URI esta no fato de que o URL identifica um documento na Web, enquanto o URI pode identificar um recurso, seja um documento ou não [Koivunen e Miller, 2001].

A Figura 2.1 exibe também as linguagens de descrição que compõem a semântica Web. São elas: XML (eXtended Markup Language), RDF (Resource Description Framework ) e OWL (Web Ontology Language). A linguagem XML é a base para as demais linguagens de descrições, pois possibilita a criação de documentos auto-descritivos. As demais (RDF e OWL) são voltadas às descrições de recursos e com diferentes níveis de expressividade (essas diferenças serão comentadas

(14)

6 WEB SEMÂNTICA 2.1

mais adiante).

As camadas de “lógica”, “prova” e “verdade” na Figura 2.1 correspondem à obtenção de conclu-sões lógicas referentes às informações descritas. A “verdade” corresponde ao resultado da “prova” que, por sua vez, é o resultado de inferências lógicas que dependem das regras impostas ao do-mínio descrito [Koivunen e Miller, 2001]. Por fim, a camada de “assinatura digital” corresponde à assinatura associada aos documentos da Web e pode influenciar na confiabilidade das descrições utilizadas.

2.1 Linguagens da Web Semântica

2.1.1 XML - eXtensible Markup Language

A linguagem XML é uma linguagem de marcação de propósito geral, designada para descrever documentos estruturados [Breitman et al., 2007]. Porém, diferentemente do HTML, o XML não é destinado à exibição de dados num navegador.

A linguagem XML permite ao autor do documento especificar suas próprias marcações. En-quanto o HTML possui marcações fixas para parágrafos, cabeçalhos, cores, posicionamento etc, o XML dá a liberdade para que essas marcações sejam especificadas de acordo com a necessidade. Essa característica permite usar o XML para descrever a semântica de algum conteúdo, dando melhorias significativas em processos de recuperação e disseminação da informação [Almeida, 2002]. Assim, é possível descrever qualquer informação para a transmissão, processamento ou armazenamento deste por um programa [Almeida, 2002].

Das especificações dos objetivos da linguagem, um documento XML [Bray et al., 2008]: • deve ser fácel de criar;

• deve ser diretamente utilizado através da Internet; • pode suportar uma grande variedade de aplicações;

• deve facilitar a implementação de programas que o interprete; • deve ser legível para um humano;

• deve ter um design formal e conciso.

Um exemplo de documento XML é exibido no Código 2.1. 1 <?xml version="1.0"?>

2 <conjunto> 3 <edificio>

4 <nome>Palácio Gustavo Capanema</nome>

5 <data_criacao>2012−07−31 08:05:31</data_criacao> 6 <cidade>Rio de Janeiro</cidade>

7 <autor>COSTA, Lúcio Marçal Ferreira Ribeiro de Lima e</autor> 8 <geo lat=’123’ long=’456’ />

9 <endereco>

10 <rua>Rua da Imprensa, 16</rua> 11 <bairro>Centro</bairro> 12 </endereco>

13 </edificio> 14 </conjunto>

Código 2.1: Exemplo de documento XML.

No XML, uma marcação consiste de seu inicio, seu conteúdo e seu fim. Por exemplo, na linha 4, os elementos “<nome>” e “</nome>” correspondem respectivamente ao inicio e fim de uma marcação e o elemento “Palácio Gustavo Capanema” corresponde ao seu conteúdo. Uma marcação também pode ter como conteúdo outras marcações, como é o caso de “<endereco>”e “<edificio>” no exemplo, ou pode não ter conteúdo, como é o caso de “<geo>” na linha 8 (nesse caso chamada de

(15)

2.1 LINGUAGENS DA WEB SEMÂNTICA 7

elemento vazio). Além disso, as marcações podem conter atributos no formato propriedade=“valor ”, como mostra a linha 8 [Bray et al., 2008, Breitman et al., 2007].

Para que se mantenha conciso, um documento XML deve cumprir com algumas regras, das quais: toda marcação deve ter inicio e fim, todas as marcações deve estar aninhadas e o documento como um todo deve estar contido em uma única marcação [Bray et al., 2008, Breitman et al., 2007]. Nota-se que a linguagem XML é uma linguagem fácil e flexível. Um grupo de pessoas pode, por exemplo, utilizar-se de um mesmo padrão de marcação XML para descrever um documento e compartilhar essa informação através da internet, entre suas aplicações. Entende-se por padrão de marcação um conjunto explícito de declarações que permitam validar um documento XML como pertencente ou não à esse padrão.

Para isso foi formulado o DTD (Document Type Definition). Um DTD contém declarações de marcações que determinam a gramática para uma classe de documentos XML [Bray et al., 2008]. Em outras palavras, um DTD define a estrutura de um documento XML. Sendo assim, um documento XML é válido se houver um DTD associado a ele e se o documento XML cumpre com as regras expressas nesse DTD [Bray et al., 2008]. Por exemplo, para o código XML apresentado no Código 2.1, o DTD correspondente é exibido no Código 2.2.

1 <!DOCTYPE conjunto [

2 <!ELEMENT conjunto (edificio∗)>

3 <!ELEMENT edificio (nome, data_criacao, cidade, autor+, geo?, endereco)> 4 <!ELEMENT nome (#CDATA)>

5 <!ELEMENT data_criacao (#CDATA)> 6 <!ELEMENT cidade (#CDATA)> 7 <!ELEMENT autor (#CDATA)>

8 <!ELEMENT geo EMPTY>

9 <!ELEMENT endereco (rua, bairro)>

10 <!ELEMENT rua (#CDATA)>

11 <!ELEMENT bairro (#CDATA)>

12

13 <!ATTLIST geo lat CDATA #REQUIRED> 14 <!ATTLIST geo long CDATA #REQUIRED> 15 ]>

Código 2.2: DTD que valida o código XML apresentado em Código 2.1.

O DTD apresentado no Código 2.2 exibe um conjunto de regras aplicadas a cada marcação XML. No código, “ELEMENT” representa as marcações existentes num documento XML. Cada marcação definida pode especificar como conteúdo um conjunto de outras marcações (como é o caso da marcação “edificio”), um conjunto de caracteres (especificação “#CDATA”), ou ainda pode especificar que a marcação em si não irá possuir conteúdo (especificação “EMPTY”). De maneira similar, “ATTLIST” representa os atributos existentes num documento XML, especificando (nessa ordem) a qual marcação o atributo pertence, qual o seu rótulo, o tipo de dado e se é obrigatório ou não. Adicionalmente, o DTD permite especificar, em “ELEMENT”, a quantidade dos demais elementos que o compõem através dos símbolos “?”, “*” e “+”, os quais significam, respectivamente, “zero ou um”, “zero ou mais” e “um ou mais” (caso um desses símbolos não esteja especificado, os elemento deve aparecer obrigatoriamente uma única vez). [Bray et al., 2008].

Embora o DTD especifique o padrão de marcação usado num documento XML, sua linguagem que não é convencional para os padrões de linguagens da Web, i.e., linguagens de marcação. Além disso, o DTD possui expressividade limitada. Por exemplo, não é possível especificar através de um DTD o tipo de dado (número, texto, etc.) atribuído a uma marcação [Fallside e Walmsley, 2004].

Assim, baseada nos padrões da Web e de forma a possibilitar a validação de documentos XML, utiliza-se a linguagem XML Schema. XML Schema, assim como o DTD, define uma classe de documentos XML, porém com mais expressividade, permitindo a definição de tipos de dados simples (como string ou decimal ) e complexos para cada elemento [Fallside e Walmsley, 2004]. O Código 2.3 exibe o código para a validação do código XML da Figura 2.1.

1 <?xml version="1.0"?> 2

(16)

3 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 4

5 <xsd:element name="conjunto" type="tipoConjunto" /> 6

7 <xsd:complexType name="tipoConjunto"> 8 <xsd:sequence>

9 <xsd:element name="edificio" type="tipoEdificio" maxOccurs="unbounded" /> 10 </xsd:sequence>

11 </xsd:complexType> 12

13 <xsd:complexType name="tipoEdificio"> 14 <xsd:sequence>

15 <xsd:element name="nome" type="xsd:string" /> 16 <xsd:element name="data_criacao" type="xsd:string" /> 17 <xsd:element name="cidade" type="xsd:string" /> 18 <xsd:element name="autor" type="xsd:string" /> 19 <xsd:element name="geo">

20 <xsd:sequence>

21 <xsd:complexType>

22 <xsd:attribute name="lat" type="xsd:string" /> 23 <xsd:attribute name="long" type="xsd:string" />

24 </xsd:complexType>

25 </xsd:sequence> 26 </xsd:element>

27 <xsd:element name="endereco" type="tipoEndereco" /> 28 </xsd:sequence>

31 <xsd:complexType name="tipoEndereco"> 32 <xsd:sequence>

33 <xsd:element name="rua" type="xsd:string" minOccurs="1" maxOccurs="unbounded"> 34 <xsd:element name="bairro" type="xsd:string" minOccurs="1" maxOccurs="unbounded"> 35 </xsd:sequence>

38 </xsd:schema>

Código 2.3: Código XML Schema que valida o código XML apresentado em Código 2.1.

O código XML-Schema exibido no Código 2.3 também classifica o documento XML apresentado no Código 2.1. A especificação é mais intuitiva que o correspondente em DTD. E a expressividade é maior. Note, por exemplo, a especificação de tipos de dados entre as linhas 15 e 27; maior expres-sividade na definição de mínimos e máximos nas linhas 33 e 34; e o uso de um namespace na linha 5.

Um namespace define uma referência para uma coleção de tipos e declarações em XML Schema, os quais serão referenciados por um prefixo ao longo do documento [Fallside e Walmsley, 2004]. No Código 2.3, é definido o prefixo “xsd” cujas definições são encontradas na Web através do endereço “http://www.w3.org/2001/XMLSchema”. A utilização de namespaces é útil para que haja a distinção entre as definições utilizadas no documento [Fallside e Walmsley, 2004]. Por exemplo, na linha 15 é especificado que o elemento “nome” é do tipo “string”, cuja definição deve ser encontrada no endereço do namespace “xsd”. Poderiam haver nesse mesma especificação diversos namespaces, onde cada um distingue suas definições dos demais [Fallside e Walmsley, 2004].

2.1.2 RDF - Resource Description Framework

Embora o XML possibilite a descrição de recursos na Web, como saber, por exemplo, se dois arquivos XML distintos estão se referindo ao mesmo recurso? Ou ainda, como saber se uma marcação “nome” em um arquivo XML corresponde à mesma semântica da marcação “nome” num outro arquivo XML? A utilização do XML Schema e de namespaces auxilia na definição da estrutura de um arquivo XML. No entanto, o XML ainda é muito flexível e não possui nenhuma formalidade na estruturação da informação.

(17)

A linguagem RDF tem como finalidade descrever recursos [Manola e Miller, 2004] e, diferente do XML, possui uma forma explícita para a descrição de recursos e informações. Por exemplo, considere a frase “Palácio Gustavo Capanema fica na cidade de Rio de Janeiro”. Em XML, há diversas formas de descrever essa informação, como mostra os trechos de códigos no Código 2.4.

1 <edificio>

2 <nome>Palácio Gustavo Capanema</nome> 3 <cidade>Rio de Janeiro</vive_em>

4 </edificio> 5

6 <cidade nome="Rio de Janeiro">

7 <edificio>Palácio Gustavo Capanema</edificio> 8 </cidade>

9

10 <edificio nome="Palácio Gustavo Capanema" cidade="Palácio Gustavo Capanema" />

Código 2.4: Três formas de representação de uma mesma informação em XML.

Todas as diferentes formas exibidas no Código 2.4 estão corretas, pois descrevem a informação. No entanto, estruturalmente não está claro qual a melhor forma de representar os recursos e a relação entre eles [Berners-Lee, 1998].

Um documento RDF, por outro lado, define um conjunto de triplas na forma t =< s, p, o >, onde [Klyne e Carroll, 2004]:

• s, ou sujeito, é um recurso;

• p, ou predicado, é uma propriedade de s;

• o, ou objeto, é o valor da propriedade p para o recurso s. Uma tripla RDF representa um grafo como exibido na Figura 2.2.

Figura 2.2: O grafo de uma tripla RDF.

Na Figura 2.2, a seta que representa o predicado obrigatoriamente parte do sujeito com direcão ao objeto. O sujeito é o recurso Web que deseja-se descrever, o predicado é alguma propriedade deste sujeito, e o objeto é o valor do predicado para esse sujeito (que pode ser uma cadeia de caracteres ou um outro recurso). Por exemplo, ao considerar novamente a frase “Palácio Gustavo Capanema fica na cidade de Rio de Janeiro”, obtemos o grafo ilustrado na Figura 2.3

Figura 2.3: Exemplo de um grafo RDF.

Na Figura 2.3, “Palácio Gustavo Capanema”, um edifício, reside na cidade do Rio de Janeiro, uma cidade. Se esses conceitos foram descritos em arquivos RDF identificados por uma URI, poderão ser localizados na rede. Logo, por exemplo, é possível extender as propriedades de “Palácio Gustavo Capanema” num grafo RDF. A Figura 2.4 exibe um grafo mais completo.

Os endereços Web exibidos na Figura 2.4 são exemplos que representam uma referência a um recurso Web que contém maiores informações sobre o recurso em questão. As únicas exceções são os valores para as propriedades “nome” e “data_criacao”, os quais são valores literais.

(18)

Figura 2.4: Exemplo de um grafo RDF mais completo.

A representação desse grafo em um documento RDF possui, diferentemente do XML, uma única estruturação. O RDF define um conjunto de marcações XML específicos para descrever os recursos, referenciado como RDF/XML [Manola e Miller, 2004] 1. Por simplicidade, “RDF” e “RDF/XML” serão usados como sinônimos ao longo do texto. O código RDF/XML da Figura 2.4 é exibido no Código 2.5. 1 <?xml version="1.0"?> 2 3 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22−rdf−syntax−ns#" 4 xmlns:ex="http://edificio.vocab.com/"> 5 6 <rdf:Description rdf:about="http://palaciocapanema.exemplo.com/"> 7 <rdf:type rdf:resource="http://edificio.vocab.com#Edificio" /> 8 <ex:nome>Palácio Gustavo Capanema</ex:nome>

9 <ex:data_criacao rdf:datatype="http://www.w3.org/2001/XMLSchema#string"> 10 2012−07−31 08:05:31 11 </ex:data_criacao> 12 <ex:cidade rdf:resource="http://riodejaneiro.exemplo.com/" /> 13 <ex:autor rdf:resource="http://luciomarcal.exemplo.com/" /> 14 </rdf:Description> 15 16 </rdf:RDF>

Código 2.5: Código RDF do grafo exibido na Figura 2.4.

No Código 2.5, a marcação “rdf:Description” (na linha 6) define o recurso que será descrito. Entre as linhas 8 e 13 são definidas as propriedades do recurso. Duas dessas propriedades, linhas 12 e 13, referenciam um outro recurso na Web. As demais, linhas 8 e 11, possuem um conjunto de caracteres como valor. Note que a propriedade “data_criacao” conta com a definição do tipo do dado [Beckett, 2004].

Nas linhas 3 e 4 são definidos os namespaces utilizados nesse documento RDF. Assim como na linguagem XML, um namespace em RDF tem o objetivo de distinguir definições de marcações utilizadas no documento. Porém, no contexto da linguagem RDF, esse recebe o nome de vocabulário RDF [Breitman et al., 2007].

O RDF não dispõe de mecanismos para descrever as propriedades e termos utilizados num recurso qualquer. Um vocabulário RDF permite a definição de classes, propriedades e hirarquias, através da linguagem RDF-Schema (ou RDF-S). O RDF-Schema é uma extensão semântica do RDF [Brickley e Guha, 2004]. Possibilita a descrição de grupos (ou classes) de recursos relaciona-dos e as relações entre eles. Por exemplo, a linha 6 no código RDF 2.5 especifica que o recurso

1

Há diversas outras linguagens para definir e estruturar as triplas RDF, tais como Tur-tle (http://www.w3.org/TR/turtle/ ), N3 (http://www.w3.org/TeamSubmission/n3/ ) e N-Triples (http://www.w3.org/2001/sw/RDFCore/ntriples/ ). Neste trabalho, apenas será abordada a linguagem RDF/XML.

(19)

sendo descrito é do tipo “Pessoa” cuja definição encontra-se no vocabulário especificado pela URI “http://pessoa.vocabulario.com”. O RDF-S que define esse vocabulário é exibido no Código 2.6. 1 <?xml version="1.0"?> 2 3 <rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf−schema#" 4 xmlns:rdf="http://www.w3.org/1999/02/22−rdf−syntax−ns#"> 5 6 <rdfs:Description rdf:about="http://edificio.vocab.com#Edificio"> 7 <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf−schema#Class"/> 8 </rdfs:Description> 9 10 <rdf:Description rdf:about="edificio.vocab.com#nome"> 11 <rdf:type rdf:resource="http://www.w3.org/1999/02/22−rdf−syntax−ns#Property" /> 12 <rdfs:domain rdf:resource="http://edificio.vocab.com#Edificio" /> 13 <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf−schema#Literal"/> 14 </rdf:Description> 15 16 <rdf:Description rdf:about="edificio.vocab.com#data_criacao"> 17 <rdf:type rdf:resource="http://www.w3.org/1999/02/22−rdf−syntax−ns#Property" /> 18 <rdfs:domain rdf:resource="http://edificio.vocab.com#Edificio" /> 19 <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf−schema#Literal"/> 20 </rdf:Description> 21 22 <rdf:Description rdf:about="edificio.vocab.com#cidade"> 23 <rdf:type rdf:resource="http://www.w3.org/1999/02/22−rdf−syntax−ns#Property" /> 24 <rdfs:domain rdf:resource="http://edificio.vocab.com#Edificio" /> 25 <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf−schema#Resource"/> 26 </rdf:Description> 27 28 <rdf:Description rdf:about="edificio.vocab.com#autor"> 29 <rdf:type rdf:resource="http://www.w3.org/1999/02/22−rdf−syntax−ns#Property" /> 30 <rdfs:domain rdf:resource="http://edificio.vocab.com#Edificio" /> 31 <rdfs:range rdf:resource="http://www.w3.org/2000/01/rdf−schema#Resource"/> 32 </rdf:Description> 33 34 </rdf:RDF>

Código 2.6: Código RDF-S que define o vocabulário usado no Código RDF 2.5.

O código RDF-S acima define o vocabulário usado para descrever a instância no Código RDF 2.5. Entre as linhas 3 e 4 estão definidos os vocabulários usados no documento (note que a linguagem RDF-S define a si mesma através do vocabulário especificado na linha 3). A classe “Edificio” é definida na linha 6. Uma classe, em RDF-S, é qualquer recurso cuja propriedade “rdf:type” tem valor igual a “rdfs:Class” [Breitman et al., 2007, Brickley e Guha, 2004]. Entre as linhas 10 e 28 são definidas as propriedades. Uma propriedade, em RDF-S, é qualquer recurso cujo valor atribuído a “rdf:type” tem valor igual a “rdfs:Property” [Breitman et al., 2007, Brickley e Guha, 2004]. Na definição de uma propriedade, “rdfs:domain” e “rdfs:range” especificam, respectivamente, a qual classe essa propriedade é aplicada e a qual classe pertence seu valor. No código, as propriedades “nome” e “data_criacao” tem, como valor de “rdfs:range”, a classe de literais (“rdfs:Literal”), a qual define como valor qualquer sequência de caracteres. E as propriedades “cidade” e “autor” possuem, para a propriedade“rdfs:range”, o valor “rdfs:Resoruce”. Por definição, toda classe RDF é subclasse da classe “rdf:Resource”, significando que qualquer recurso pode ser dado como valor para as propriedades “cidade” e “autor” [Brickley e Guha, 2004, Hayes, 2004, Manola e Miller, 2004].

Dado um vocabulário que define uma classe C, uma instância ou indivíduo de C é qualquer re-curso cujo valor para a propriedade “rdf:type” seja igual a C [Breitman et al., 2007, Brickley e Guha, 2004, Manola e Miller, 2004]. Dessa forma, por exemplo, o indivíduo “Palácio Gustavo Capanema” descrito no Código 2.5 é uma instância da classe “Edificio” definida no código RDF-S 2.6.

As descrições de um vocabulário em RDF Schema são similares a definições de classe em lin-guagens orientadas a objetos. Na perspectiva de uma linguagem orientada a objetos, uma classe define as diversas propriedades para os objetos que esta classifica. Analogamente, num vocabulário

(20)

RDF são encontradas as definições de classes e propriedades em termos das classes dos recursos a que eles se aplicam [Brickley e Guha, 2004].

2.1.3 OWL - Web Ontology Language

A linguagem OWL (Web Ontology Language) permite a definição de classes, propriedades e a descrição de indivíduos [McGuinness e van Harmelen, 2004, Smith et al., 2004]. É definido como um vocabulário, assim como RDF e RDF-S, porém possui maior poder de expressividade. Portanto, uma descrição em OWL utiliza uma coleção de triplas RDF, as quais usam o vocabulário do OWL [Breitman et al., 2007, McGuinness e van Harmelen, 2004].

O vocabulário OWL contém conceitualizações que facilitam a interpretação do conteúdo por um computador [Breitman et al., 2007]. O OWL supera o RDF-S em expressividade por permitir (além das definições contidas no própro RDF-S) [Breitman et al., 2007, McGuinness e van Harmelen, 2004]:

• Mais descrições na relação entre classes (por exemplo, disjunção, união, restrições, equivalen-cias, intersecções, complemento etc);

• Mais descrições entre as propriedades (por exemplo, propriedade transitiva, simétrica, funci-onal, inversa e restrições tais como a cardinalidade, quantidade e restrições de valor ); A expressividade da linguagem OWL é organizada em três sub-linguagens, mostradas na Tabela 2.1.[Breitman et al., 2007, McGuinness e van Harmelen, 2004]

Tabela 2.1: Sub-linguagens OWL.

OWL Lite Das três é a menos expressiva. Oferece hierarquida de classes e proprie-dades, e um conjunto de regras mais limitado

OWL DL Mais expressiva. O nível de expressividade é limitado à decidibilidade do problema, de modo que possa ser computável

OWL Full É a linguagem como um todo e sem limitações, porém ignora a questão de decidibilidade

Como este trabalho está voltado ao uso de descrições em RDF (as quais predominam no Linked Data), não será dada muita atenção à linguagem OWL.

2.2 Linked Data

O Linked Data é uma série de boas práticas para estruturar e conectar os dados na Web [Hausenblas, 2009a]. Essa série de boas práticas cria e alimenta uma enorme rede semântica, conec-tando recursos de diferentes lugares na Web.

Tecnicamente, Linked Data refere-se à publicação de recursos na Web num formato em que sejam interpretados por computadores, com descrições explicitamente definidas. Esses recursos devem possuir links para recursos externos e, eventualmente, os recursos externos devem ter links para outros recursos [Bizer et al., 2009].

Usando a linguagem descritiva RDF, o Linked Data é o grafo formado por diversos recursos descritos espalhados pela Web [Bizer et al., 2009]. Em contraste com a visão da web semântica sobre níveis de ontologia e inferência, o Linked Data se refere puramente a publicar dados em RDF. Essa simplificação facilita a publicação dos dados e permite uma ampla adoção da tecnologia [Hausenblas, 2009a].

Tim Berners-Lee, um dos pesquisadores junto a W3C do projeto Linked Data, escreveu os quatro princípios do Linked Data [Berners-Lee, 2009, Bizer et al., 2009, Hausenblas, 2009a]. Segundo Berners-Lee, desrespeitar esses princípios não afeta a rede, mas fará com que a oportunidade de torná-la interconectada seja perdida [Berners-Lee, 2009]. São eles:

(21)

2.2 LINKED DATA 13

2. Usar HTTPs (HyperText Transfer Protocol ) URIs para que os recursos possam ser acessados; 3. Ao acessar um recurso Web, este deve providenciar informações úteis utilizando os padrões

(RDF e RDF-S, por exemplo);

4. Incluir links para outros URIs, para habilitar a descoberta de novos recursos Web.

O primeiro princípio refere-se à identificação de um recurso, que deve ser através de seu URI. O segundo princípio aponta para o uso do protocolo HTTP para o acesso aos recursos. O HTTP é atualmente um protocolo altamente difundido, e por isso ele é utilizado. O terceiro princípio sustenta o uso do RDF como a linguagem de descrição padrão. E o último princípio sugere que o recurso acessado deve ter links para outros recursos, de forma a tornar a rede mais interconectada.

O projeto mais visível a exemplo de adoção e aplicações é o projeto Linked Open Data [Bizer e Health, 2011, Bizer et al., 2009]. Em 2007, inicialmente, o projeto Linked Data contava apenas com o grupo envolvido na pesquisa. O objetivo do projeto era identificar dados na Web que pudessem ser com-partilhados (livres), convertê-los para RDF de acordo com os princípios do Linked Data e publicá-los [Bizer e Health, 2011, Bizer et al., 2009]. Desde o inicio, o projeto esteve aberto a qualquer publi-cação segundo os princípios do Linked Data [Bizer e Health, 2011]. Esse foi um fator determinante no crescimento da rede. A Figura 2.5 exibe o crescimento da rede2. Ela é apenas um indicativo do quanto a rede cresceu com o passar do tempo, mostra um grafo onde cada nó represente um conjunto de triplas RDF (ou repositório) e os arcos representam a existência de links entre os repo-sitórios. Quanto maior o nó do grafo, maior é a quantidade de triplas RDF contidas nele, e quanto mais espesso o arco, maior a quantidade de links entre eles. Note também que há arcos direcionais e bidirecionais, os quais representam a existência de links entre os repositórios em uma dada direção.

Figura 2.5: O crescimento da rede Linked Data de maio de 2007 a março de 2009 [Bizer e Health, 2011].

Diversas organizações adotaram o Linked Data como forma de publicar dados. O resultado, como mostra a Figura 2.5 é um grafo contendo informações sobre diversos tópicos tais como localizações

2

(22)

geográficas, pessoas, companhias, livros, publicações científicas, filmes, músicas, televisão e muito mais [Hausenblas, 2009a]. A Figura 2.6 exibe o tamanho da rede Linked Data em Setembro de 2011. O Linked Data pode ser visto como uma camada adicional na Web, e possui algumas das mesmas características dos clássicos documentos HTML, além de caracteríticas adicionais, tais como [Bizer e Health, 2011]:

• Os dados são genéricos e podem conter todo tipo de informação; • Qualquer pessoa pode publicar dados na rede;

• Os dados podem representar informações contraditórias; • A existência de links entre os recursos;

• As publicações de dados não são limitadas aos vocabulários pré-existentes, i.e., os desenvol-vedores podem criar novos vocabulários;

• O dado é auto-descritivo. Se alguma aplicação, enquanto consumindo dados no Linked Data, encontrar alguma informação descrita com o uso de um vocabulário não familiar, basta que a aplicação acesse o URI que define o vocabulário em questão para identificar os termos e suas definições;

• O uso do padrão HTTP para o acesso, e do padrão RDF para a descrição dos dados possibi-litam mais facilmente o acesso a informação do que aquele feito por APIs na Web.

2.2.1 Publicação e Consumo

O uso da rede Linked Data pode ser identificado basicamente através de duas formas: publicação e consumo. A publicação de dados na rede Linked Data refere-se a estruturação e descrição de um conjunto de dados em RDF, tornando-os disponíveis na rede [Hausenblas, 2009b]. E o consumo refere-se a descoberta de dados na rede e o acesso a eles [Hausenblas, 2009b].

A publicação de dados na rede Linked Data requer a adoção da estrutura dessa rede [Bizer e Health, 2011], bem como também a adoção dos princípios básicos listados por Berners-Lee [Berners-Lee, 2009]. É importante notar que a adoção destes princípios e tecnologia não significa o abandono dos gerenciadores e tecnologias já existentes, mas sim a adição de uma nova camada técnica conectada ao Linked Data [Bizer e Health, 2011].

Há diversas formas para se efetuar a publicação no Linked Data [Bizer e Health, 2011]. A Figura 2.7 apresenta alguma delas e divide a publicação em três etapas:

1. Preparação dos dados; 2. Armazenamento dos dados; 3. Publicação dos dados.

A preparação dos dados consiste na conversão da informação, estruturado ou não (tipo texto), para a linguagem RDF. Após a extração o armazenamento pode ser realizado por um repositório RDF, ou através de arquivos de texto RDF. Note que nem todo dado necessita ser convervito para RDF, podendo permanecer num banco de dados ou com um acesso restrito a uma API. Para finalmente tornar os dados públicos, existen diversas opções dentre as que estão presentes na Figura 2.7 [Bizer e Health, 2011]:

• A publicação pode ser realizada diretamente do banco de dados através de um conversor para a linguagem RDF;

(23)

2.2 LINKED DATA 15

(24)

Figura 2.7: Formas de publicação na rede Linked Data (figura traduzida de [Bizer e Health, 2011]).

• A publicação pode ser realizada através de um Sistema Gerenciador de Conteúdo (como Dru-pal3, por exemplo). Nesse caso, a informação é publicada no format RDFa (RDF in Attributes, é o uso de RDF diretamente num código HTML [Adida et al., 2012]);

• Se o acesso a informação é realizado por uma API (Application Programming Interface), a publicação pode ser feita por um conversor que trasforma o resultado de uma consulta na linguagem RDF. Geralmente, esses conversores são customizados devido a grande heteroge-neidade dessas APIs;

• Caso os arquivos RDF convertidos tenham sido armazenados num repositório próprio, esse o repositório já possui uma interface permitindo o acesso aos recursos RDF;

• Ou os arquivos RDF podem simplesmente ser disponibilizados através de um servidor comum, como o Apache4, por exemplo.

A escolha na forma de publicação dos dados depende muito da quantidade de dados a ser publicada e da frequência com que esses dados são alterados. Quantidades pequenas de dados com pouca atualização/alteração exigem pouco esforço e, eventualmente, podem ser convertidos para RDF manualmente [Bizer e Health, 2011]. Porém, dados em grandes quantidade e/ou com muitos períodos de atualização/alteração exigem métodos automatizados e/ou customizados de publicação [Bizer e Health, 2011].

Entende-se por “consumo” os processos da descoberta, do acesso e do processamento de recursos [Hausenblas, 2009b]. Dado um endereço URI, o processo de descoberta refere-se à necessidade de buscar um recurso no Linked Data referente a esse URI. O acesso define o método com o qual o recurso será obtido, se através de uma consulta SPARQL ou da obtenção de um arquivo RDF. E o processamento refere-se ao uso feito com os dados RDF obtidos. Tipicamente, o resultado do processamento é, novamente, a descoberta de um novo conjunto de endereços URI, que podem ser acessados e processados [Hausenblas, 2009b].

3

https://drupal.org/

(25)

2.2 LINKED DATA 17

2.2.2 O projeto DBpedia

O projeto DBpedia5 disponibiliza na rede Linked Data mais de 1,95 milhões de informações sobre diversas tópicos incluindo pessoas, lugares, álbuns de música e filmes, com links para imagens, páginas, arquivos RDF externos etc [Auer et al., 2007].

O objetivo do projeto DBpedia é a conversão dos dados da Wikipedia6 para o padrão RDF [Auer et al., 2007]. Como outras aplicações na Web, o Wikipedia tem sua busca limitada a palavras, o que ocasiona num acesso muito limitado à sua base de dados [Auer et al., 2007]. Com sua conversão para o formato RDF e publicação segundo os princípios do Linked Data, torna-se possível realizar buscas mais sofisticadas.

O conjunto de dados disponibilizado pela DBpedia é interligado com outros repositórios, como o Geonames7, MusicBrainz8 e o WordNet9 [Auer et al., 2007].

Os recursos da DBpedia são identificados pela URI “http://dbpedia.org/resource/<recurso>”, onde “<recurso>” deve ser substituído pelo nome do recurso desejado. O acesso a um recurso pode ser feito através de pontos de acesso SPARQL, através do acesso diretamente ao recurso RDF ou ainda através de uma interface mais amigável proporcionado pelo acesso usando o navegador Web [Auer et al., 2007].

Os dados extraídos disponibilizados como recursos RDF pela DBpedia provêem das infobox, um vocabulário controlado pela Wikipedia para descrever sucintamente os recursos [Auer et al., 2007]. A Figura 2.8 (a) exibe um trecho de um código do Wikipedia que gera o infobox exibido na 2.8 (b).

Figura 2.8: Exemplo de um código do Wikipedia e seu respectivo infobox. Figura extraída de [Auer et al., 2007].

Notadamente, o projeto DBpedia oferece diversos recursos na Web. Trata-se de um excelente ponto de partida para a obtenção de recursos e links para novos recursos na Web sobre praticamente qualquer tópico. 5 http://dbpedia.org/ 6 http://www.wikipedia.org 7 http://www.geonames.org/ 8_{http://musicbrainz.org/} 9 http://wordnet.princeton.edu/

(26)

(27)

Capítulo 3

Similaridade entre instâncias RDF

Com o propósito de realizar mineração de dados sobre um conjunto de instâncias definidas em RDF, faz-se necessário definir uma métrica RDF a ser usada pelo algoritmo de mineração. Esse capítulo detalha a métrica de similaridade entre as instâncias usadas neste trabalho.

3.1 Definição formal de RDF

Antes de prosseguir com a definição da métrica de similaridade, é necessário apresentar uma definição mais formal das instâncias e dos vocabulários RDF. Como apresentado anteriormente, uma instância é descrita segundo um vocabulário que define classes e propriedades.

Um vocabulário é definido como uma tupla V = hC, P, H, propi, com C ∩ P = ∅, onde: • C é um conjunto de classes ou conceitos;

• P é um conjunto de propriedades;

• H define uma hierarquia de classes (ou uma hierarquia taxonômica de classes), de forma que H ⊆ C × C;

• prop é uma função P → C × C que associa propriedades não-taxonômicas entre classes. Dada uma propriedade p ∈ P com função prop(p) = (c₁, c2), c1 é chamado de domínio de p e c2

é chamado alcance de p. Com o intuito de facilitar a notação, a expressão H(c1, c2) (com c1, c2∈ C)

significa que c1 é uma sub-classe (ou sub-conceito) de c2. De maneira similar, a expressão p(c1, c2)

(com c₁, c2 ∈ C) é o mesmo que prop(p) = (c1, c2).

Convém também notar que o conjunto H conta com a propriedade transitiva entre as classes e sub-classes. Por exemplo, se H(A, B) e H(B, C) estão definidos, então H(A, C).

Finalmente, são chamados de atributos todas as propriedades cujo alcance seja definido para a classe “Literal” (alc(prop(p)) = LITERAL). Um valor literal é qualquer sequência de caracteres (string) incluindo números ou formatos de data [Brickley e Guha, 2004].

Como exemplo, a Figura 3.1 exibe um vocabulário. Nessa figura são definidos um conjunto de

classes C = {Recurso, País, Idioma, . . . }, um conjunto de propriedades P = {presidente, acredita_em, fala}, um conjunto de hierarquias H = {{Idioma, Recurso}, {Cristianismo, Religião}, . . . }, e as funções de

propriedades prop(fala) = (País, Idioma), prop(presidente) = (País, LITERAL) e prop(acredita_em) = (Pais, Religião).

Segundo esse vocabulário, cada país acredita em uma religião que, através da relação de hie-rarquia entre classes, pode ser o “Cristianismo” ou a “Muçulmana”. Similarmente, cada país possui um idioma e um presidente. Por definição, no RDF, todas as classes são sub-classes de “Recurso” [Brickley e Guha, 2004, Manola e Miller, 2004].

Por sua vez, um repositório RDF é uma tupla R =< V, I, L, inst, instp >, onde: • V é um vocabulário;

• I é um conjunto de instâncias;

(28)

20 SIMILARIDADE ENTRE INSTÂNCIAS RDF 3.2

Figura 3.1: Exemplo de um vocabulário RDF.

• L é um conjunto de literais; • inst é uma função C → 2I_;

• instp é uma função P → 2I×(I∪L)_.

A definição inst associa cada instância à classe que o define. Com o intuito de facilitar a notação, para inst(C) = I escreve-se também C(I). E a definição instp associa propriedades de uma instância à outra instância ou a um valor literal.

A Figura 3.2 exibe um exemplo de repositório RDF usando o vocabulário exibido na Figura 3.1.

Figura 3.2: Exemplo de um repositório RDF usando o vocabulário exibido na Figura 3.1. Os círculos escuros representam as instâncias e os claros, as classes.

Na Figura 3.2 são definidos o conjunto de instâncias I = {Irã, Finlândia, . . . }; o conjunto de literais L = {“Sauli Niinistö”, “Joachim Gauck”, . . . }; as funções inst(País) = {Irã, Finlândia, . . . }, inst(Idioma) = {Persa, Finlandês, . . . } e assim por diante; e as funções instp(acredita_em) =

(29)

3.2 MÉTRICA DE SIMILARIDADE ENTRE INSTÂNCIAS RDF 21

3.2 Métrica de Similaridade entre Instâncias RDF

Uma métrica de similaridade δ, aplicada aos elementos de um conjunto U = u0, . . . , un, é válida

se atender às seguintes propriedades [Euzenat e Shvaiko, 2007]: 1. sim(ui, uj) ≥ 0 (positividade);

2. sim(u_i, uj) = sim(uj, ui) (comutatividade);

3. sim(ui, uj) = 1 se, e somente se, ui= uj (maximidade).

Se a métrica de similaridade sim estiver definida no intervalo [0, 1], sim é uma métrica norma-lizada [Euzenat e Shvaiko, 2007].

Desta forma, uma função sim : U ×U → [0, 1] calcula o grau de similaridade entre dois elementos do conjunto U . Quanto mais próximo de 1 for o resultado calculado, maior o grau de similaridade entre os elementos.

Nesse trabalho, a métrica utilizada é normalizada e é definida sobre o espaço I de instân-cias descritas em RDF. A métrica apresentada é baseada no trabalho de Maeche e Zacharias [Maedche e Zacharias, 2002].

Dadas duas instâncias i e j ∈ I, a definição da métrica considera os seguintes critérios [Maedche e Zacharias, 2002]:

• Similaridade Taxonômica (ST): Computa a similaridade entre as instâncias i e j conside-rando as classes e superclasses que os definem;

• Similaridade Relacional (SR): Computa a similaridade entre i e j considerando o relacio-namento dessas instâncias com demais outras através das suas propriedades;

• Similaridade Literal (SL): Computa a similaridade entre i e j considerando as propriedades cujo alcance é um literal (cadeias de caracteres).

Cada uma das similaridades tem como resultado um valor no intervalo [0, 1]. A similaridade entre as instâncias i e j é então definida através da expressão:

sim(i, j) = α × ST (i, j) + β × SR(i, j) + γ × SA(i, j)

α + β + γ (3.1)

Onde α, β e γ ∈ R são os pesos associados a cada uma das medidas de similaridade, de forma que α + β + γ 6= 0.

Similaridade Taxonômica

Dada duas instâncias, a similaridade taxonômica mede o quão são similares considerando as classes (e classes ancestrais) que os definem. Quanto mais classes em comum houver entre duas instâncias, maior é a sua similaridade taxonômica. Dadas duas instâncias i, j ∈ I, a similaridade taxonômica (ST) é calculada com a expressão:

ST (i, j) =

(_{EC(C(i),C(j))}

2 se i 6= j

1 caso contrário (3.2)

Na expressão, C(i) refere-se à classe que define a instância i. Por sua vez, a expressão Equiva-lência de Conceito (EC) é definida como:

EC(ci, cj) =

|CA(ci) ∩ CA(cj)|

|CA(ci) ∪ CA(cj)|

(3.3) Onde as Classes Ancestrais (CA) são obtidas através da expressão recorrente mostrada abaixo:

(30)

CA(c) = (

{c} ∪ CA(c0_{, H)} _{se ∃c}0 _{∈ C ∧ ∃(c, c}0_{) ∈ H}

{c} caso contrário (3.4)

A expressão 3.4 retorna, para uma classe c qualquer, todas as superclasses que a definem. Como exemplo, considere as instâncias “Católica Romana” e “Muçulmana Shia” exibidas na Figura 3.2. A similaridade taxonômica entre elas é igual a:

ST (“Católica Romana”,“Muçulmana Shia”) =

= EC(“Cristianismo”, “Muçulmana”) 2 = |CA(“Cristianismo”) ∩ CA(“Muçulmana”)| |CA(“Cristianismo”) ∪ CA(“Muçulmana”)|× 1 2 = |{“Religião”, “Recurso”}|

|{“Religião”, “Recurso”, “Cristianismo”, “Muçulmana”}| × 1 2 = 2 4 × 1 2 = 0, 75 (3.5) Similaridade Relacional

Se duas instâncias quaisquer possuem, através de uma mesma propriedade p, uma conexão com uma mesma terceira instância, então estas duas instâncias são mais similares se comparadas a outras duas que possuem conexões com instâncias diferentes através de p [Maedche e Zacharias, 2002]. Por exemplo, na Figura 3.1, países que tem como crença a religião católica são mais similares se comparados a países com crença em religião protestante do que se comparados a países com crença muçulmana.

Dadas duas instâncias i e j, a Similaridade Relacional (SR) é definida como:

SR(i, j) = P p∈P CS(i,j)OR(i, j, p) + P p∈P CE(i,j)OR(i, j, p) |P CS(i, j)| + |P CE(i, j)| (3.6)

A expressão 3.6 leva em conta somente as propriedades comuns entre i e j, pois as dife-renças entre as demais propriedades já são consideradas no cálculo da Similaridade Taxonômica [Maedche e Zacharias, 2002].

Para as instâncias i e j são avaliadas as similaridades entre suas propriedades comuns de saída e entrada, ou seja, entre suas propriedades onde i e j são considerados domínio e alcance. Es-sas propriedades são obtidas através das expressões P CS(i, j) (Propriedades Comuns de Saída) e P CE(i, j) (Propriedades Comuns de Entrada), definidas pelas expressões:

P CS(i, j) = P S(i) ∩ P S(j) (3.7)

P CE(i, j) = P E(i) ∩ P E(j) (3.8)

As Propriedades de Saída (P S) e as Propriedades de Entrada (P E) são definidas como: P S(i) = {p | p ∈ P ∧ dom(p) ∈ CA(C(i)) ∧ alc(p) 6= LIT ERAL} (3.9)

P E(i) = {p | p ∈ P ∧ alc(p) ∈ CA(C(i))} (3.10)

Note que, em ambas expressões, a propriedade p a ser obtida deve estar definida como alcance ou domínio de alguma classe ancestral de i. Se p é uma propriedade que tem como alcance uma classe ancestral de C(i), então, por herança, a classe C(i) também pode ser referenciada por p.

(31)

3.2 MÉTRICA DE SIMILARIDADE ENTRE INSTÂNCIAS RDF 23

Além disso, note que o alcance de p, em P S(i), não pode pertencer à classe Literal. Finalmente, a similaridade entre i e j através de p, é dada pela expressão:

|IA(i,p)| se|IA(i, p)| ≥ |IA(j, p)| P

k∈IA(j,p)maxSim(k,l)|∀l∈IA(i,p)

|IA(j,p)| caso contrário

(3.11)

Onde IA, Instância Associada a i através de p, é definida como:

IA(i, p) = {j|j ∈ I ∧ (P (i, j) ∨ P (j, i))} (3.12)

A expressão 3.12 retorna a instância associada a i através de p. Eventualmente, um conjunto com várias instâncias pode ser retornado, pois o RDF permite a associação de várias instâncias através de uma mesma propriedade.

Note que existe uma recursividade na expressão 3.11, que calcula a similaridade entre as instân-cias associadas a i e j através de p, obtendo a de maior similaridade. Para evitar que esse processo se torne infinito, é definido um valor de máxima profundidade no processo recursivo. Ao alcançar essa profundidade, a média aritmética entre a similaridade taxonômica e a similaridade literal é retornada [Maedche e Zacharias, 2002].

Similaridade Literal

Como comentado anteriormente, nem todas as propriedades definidas em um vocabulário são associadas a uma instância. Nesse último caso, são associadas a valores literais. São chamados Atributos o conjunto de propriedades cujo alcance pertence à classe Literal. Então, seja A ⊆ P o conjunto dos atributos, A é definido como:

A = {p|p ∈ P ∧ alc(p) = LITERAL} (3.13)

A Similaridade Literal (SL) entre duas instâncias i e j é definida como:

SL(i, j) = P

a∈AC(i,j)OA(i, j, a)

|ACi, j| (3.14)

Similar às definições da similaridade relacional, a similaridade literal é realizada considerando somente atributos em comum existentes entre as duas instâncias i e j. Os Atributos em Comum (AC) são obtidos com a expressão:

AC(i, j) = AI(i) ∩ AI(j) (3.15)

Onde os Atributos de uma Instância (AI) são obtidos pela expressão:

AI(i) = {a|a ∈ A ∧ dom(a) ∈ CA(i)} (3.16)

Finalmente, a similaridade entre i e j através de a, é dada pela expressão: OA(i, j, a) =        0 se V A(i, a) = ∅ ∨ V A(j, a) = ∅ P

x∈V A(i,a)max{lsim(x,y)|∀y∈V A(j,a)}

|V A(i,a)| se |V A(i, a)| ≥ |V A(j, a)| P

x∈V A(j,a)max{lsim(x,y)|∀y∈V A(i,a)}

|V A(j,a)| caso contrário

(3.17)

Onde o Valor do Atributo (V A) é definido como:

(32)

Convém acrescentar que, na expressão 3.17, lsim é definida como lsim : L × L → [0, 1]. Dessa forma, essa função pode variar de acordo com o tipo de dado a ser comparado. Para este trabalho os tipos de dados não são diferenciados, e lsim é definida como sendo a distância de Levenshtein [Levenshtein, 1966]. A distância de Levenshtein é o menor número de inserções, deleções ou substi-tuições capaz de transformar uma string s1 em outra s2 [Levenshtein, 1966, Marzal e Vidal, 1993,

Yujian e Bo, 2007]. Usualmente as operações de inserão e deleção tem custo 1, e a operação de substituição tem custo 2 [Levenshtein, 1966, Marzal e Vidal, 1993, Yujian e Bo, 2007].

Portanto, a função lsim foi definida da seguinte forma:

lsim(x, y) = 1 −Levenshtein(x, y)

|x| + |y| (3.19)

(33)

Capítulo 4

Predição de

tags usando Agrupamento Hierárquico

Agrupamento (do inglês clustering) é uma técnica que classifica, segundo algum critério, um con-junto de instâncias (ou elementos) em clusters (ou grupos) [Begelman et al., 2006, Grimnes et al., 2008, Manning e Schütze, 1999].

Clusterização Hierárquica (Hierarcihcal Clustering) é uma técnica de clusterização onde um cluster (ou agrupamento) C pode ser subdividido em outros dois agrupamentos {c₁, c2}, tal que

c1, c2 ∈ C e c1∩ c2 = ∅ [Witten e Frank, 2005]. Por exemplo, a Figura 4.1 mostra um exemplo de

clusterização hierárquica usando diagramas de Venn. Nela, os pontos A e B são similares e formam o cluster {A, B}. O mesmo ocorre com o cluster {D, E}. Por sua vez C é mais similar ao cluster {A, B}, formando o cluster {C, {A, B}}. Finalmente, ambos os clusters são agrupados formando um único agrupamento.

Figura 4.1: Exemplo de clusterização hierárquica usando diagramas de Venn.

Usualmente, a representação da estrutura resultante de uma clusterização hierárquica é realizada através de um dendrograma [Hastie et al., 2001, Manning e Schütze, 1999, Witten e Frank, 2005]. Um dendrograma representa um diagrama similar a uma representação de árvore, onde cada nó representa um cluster. A Figura 4.2 mostra um exemplo de dendrograma equivalente ao mostrado na Figura 4.1.

Figura 4.2: Exemplo de um dendrograma.

Na Figura 4.2, cada nó da árvore representa um cluster. O nó-raiz representa todo o conjunto de instâncias. Os nós-folha representam uma única instância. E cada nó interno representa o agru-pamento de dois nós-filhos [Hastie et al., 2001].

(34)

26 PREDIÇÃO DE TAGS USANDO AGRUPAMENTO HIERÁRQUICO 4.1 A B C D E A 1 0,3 0,7 0,2 0,8 B 0,3 1 0,4 0,7 0,1 C 0,7 0,4 1 0,3 0,7 D 0,2 0,7 0,3 1 0,0 E 0,8 0,1 0,7 0,0 1

Tabela 4.1: Exemplo de similaridade para um conjunto de instâncias.

Considerando um número n de instâncias, o processo de clusterização hierárquica é geralmente realizado através dos algoritmos Aglomerativo e Divisivo, como mostrados a seguir: [Hastie et al., 2001, Manning e Schütze, 1999, Witten e Frank, 2005]:

Algoritmo Aglomerativo : Trata-se de um método bottom-up de clusterização, onde, a cada passo, os clusters mais similares são unificados. Dado um conjunto S de instâncias, inicialmente cada instância é considerada como um cluster isolado. A partir daí, em cada passo, são agru-pados os clusters mais similares até que todas as instâncias de S estejam sob um único cluster [Manning e Schütze, 1999, Witten e Frank, 2005].

Algoritmo Divisivo : Trata-se de um método top-down onde, inicialmente, um conjunto S de instâncias está contido em um único cluster. A partir daí, em cada passo, determina-se qual é o clus-ter menos coerente no conjunto e esse é dividido em dois [Manning e Schütze, 1999, Witten e Frank, 2005].

Ambos os algoritmos acima necessitam de uma expressão de similaridade (ou dissimilaridade) entre as instâncias para poder criar a estrutura. De fato, o agrupamento hierárquico não faz sentido se não estiver definida uma métrica de similaridade. Essa medida pode ser, por exemplo, a distância Euclidiana entre dois pontos num plano (medida usada nos exemplos mostrados nas Figuras 4.1 e 4.2). Por sua vez, dada uma métrica de similaridade sim, a similaridade entre dois clusters C₁ e C₂ é definida pela expressão abaixo:

simCluster(C1, C2) = max{Sim(i, j)|∀i ∈ C1∧ ∀j ∈ C2} (4.1)

Em outras palavras, a similaridade entre dois clusters C₁ e C₂ é a máxima similaridade entre todas as instâncias contidas em C1 e C2 [Manning e Schütze, 1999].

Neste trabalho, por se tratar de descrições RDF, a medida de similaridade utilizada é aquela apresentada no capítulo 3. Além disso, foi usado um outro método para realizar a clusterização hierárquica: clusterização incremental [Witten e Frank, 2005]. Nesse caso, o conjunto de instâncias não é fixo. Inicialmente a árvore está vazia, e as instâncias são adicionadas uma a uma. A cada adição, a árvore é atualizada incluindo a instância na posição correta da estrutura.

Ao ser inserida, toda nova instância é considerada como um novo cluster isolado. Esse novo cluster é sempre inserido a partir do nó raiz da árvore. Então é realizado o cálculo de similaridade entre o novo cluster e o nó raiz através da expressão 4.1. Se, e somente se, o resultado da similaridade for maior que o armazenado no nó raiz, então o novo cluster será inserido abaixo dele. O próximo passo é refazer o cálculo para os filhos do nó raiz, de modo a encontrar o conjunto de instâncias mais similar àquela que está sendo inserida. Após selecionar o nó-filho mais similar, o mesmo processo é repetido até que (1) a nova instância atinja um nó-folha, ou até que (2) a primeira condição não seja mais satisfeita. Quando algum deles acontece, o novo cluster é inserido. Esse processo é mostrado no Algoritmo 1.

Como exemplo, a Tabela 4.1 exibe os valores de similaridade para o conjunto de instâncias {A, B, C, D, E}. A árvore produzida a partir do Algoritmo 1 considerando essa tabela é exibida na Figura 4.3.

Note que a árvore resultante, mostrada na Figura 4.3, independe da ordem de inserção das instâncias. Além disso, o valor de s para cada nó é sempre menor que os valores armazenados em seus nós-filhos e maior que o valor armazenado em seu nó-pai.

(35)

4.1 PREDIÇÃO DE TAGS 27

Algorithm 1 O algoritmo de inserção na árvore de clusters

Require: rootN ode: O nó raiz da árvore. Require: ins: A nova instância a ser inserida.

1: C ← new Cluster

2: C.instancia ← ins

3: if rootN ode == N U LL then

4: rootN ode ← C

5: else

6: aux ← rootN ode

7: parent ← aux

8: while aux is not leaf ∧maxSim(aux, C) > aux.similarity do

9: lef tSim ← maxSim(aux.lef t, c)

10: rightSim ← maxSim(aux.right, c)

11: minor ← min{lef tSim, rightSim}

12: aus.similarity ← max{aux.similarity, minor}

13: parent ← aux

14: if lef tSim > rightSim then

15: aux ← aux.lef t 16: direction ← lef t 17: else 18: aux ← aux.right 19: direction ← right 20: end if 21: end while 22: D ← new Cluster 23: D.lef t ← aux 24: D.right ← C

25: if parent 6= aux then

26: if direction = lef t then

27: parent.lef t ← aux 28: else 29: parent.right ← aux 30: end if 31: else 32: rootN ode ← d 33: end if 34: d.similarity ← simCluster(aux, C) 35: end if 4.1 Predição de tags

Utilizando a estrutura do agrupamento hierárquico, pode-se adaptá-la para realizar a predição de tags. O enunciado do problema de predição de tags é: dado um conjunto C de tuplas < r, T > onde r é o recurso e T é um conjunto de tags, o problema consiste em prever o conjunto de tags T para um novo recurso acrescentado em C [Heymann et al., 2008].

Para que a estrutura possa predizer tags a um recurso qualquer, deve-se partir do pressuposto de que recursos similares possuem tags similares [Oliveira et al., 2008, Sood et al., 2007]. Aplicando a métrica apresentada no Capítulo 3 ao algoritmo de agrupamento os itens mais similares serão agrupados. Uma vez que estes itens contenham uma certa quantidade de tags em comum, espera-se que qualquer outro novo item que venha a ser inserido no mesmo agrupamento receba o mesmo conjunto de tags.

(36)

28 PREDIÇÃO DE TAGS USANDO AGRUPAMENTO HIERÁRQUICO 4.1

Assim, os nós internos do agrupamento criado pelo Algoritmo 1 serão modificados de forma a conter também um conjunto de T de tags. Esse conjunto é definido como a intersecção entre os conjuntos de tags dos seus nós-filho.

Por exemplo, considere o conjunto de instâncias {A, B, C, D, E} e os valores de similaridade para estas instâncias exibidos na Tabela 4.1. Considere que cada uma dessas instâncias possua o conjunto de tags mostrado na Tabela 4.2.

Instância Tags A t1, t2, t3 B t4, t5 C t1, t5 D t1, t4, t5 E t1, t2, t3, t4

Tabela 4.2: Exemplo de conjuntos de tags associados às instâncias A, B, C, D e E.

O agrupamento produzido a partir dos valores de similaridade mostrados na Tabela 4.1 e das tags exibidas na Tabela 4.2 produz como resultado a estrutura exibida na Figura 4.4. Para toda nova instância inserida na estrutura, os nós-pais são atualizados recursivamente com a intersecção das tags contidas nos nós-filho.

Figura 4.4

A predição só pode ser realizada após o agrupamento prévio de um conjunto de instâncias já associadas a suas respectivas tags. A fase da criação desse agrupamento prévio é chamado de treinamento.

Após o treinamento, a estrutura criada pode ser usada para realizar as predições de tags. A predição funciona da seguinte forma: todo novo recurso a ser adicionado na estrutura recebe para si as tags contidas no caminho que percorre desde o nó raiz até a sua devida posição no agrupamento. Por exemplo, suponhamos a adição de uma instância F à estrutura exibida na Figura 4.4. Supo-nhamos também que F sera adicionada ao lado da instância A. F receberá, como tags, o conjunto {t₁, t2, t3}.

Para verificar se as tags preditas pelo algoritmo estão corretas, o conjunto de instâncias consi-derado (as instâncias do Arquigrafia) é dividido em dois: o conjunto de treinamento e o conjunto de testes. O conjunto de treinamento é utilizado para criar o agrupamento. E o conjunto de testes contém as novas instâncias a serem adicionadas a esse agrupamento. Para cada instância inserida, as tags preditas são comparadas com as tags originalmente atribuídas à instância e são anotados os erros e acertos.