Arquivo Digital do Livro do DesassossegoPesquisas e Recomendacoes

Andre Filipe Braz dos Santos

Dissertacao para obtencao do Grau de Mestre em

Engenharia Informatica e Computadores

Orientadores: Prof. Antonio Manuel Ferreira Rito da Silva

Prof. Manuel Jose de Freitas Portela

Juri

Presidente: Prof. Daniel Jorge Viegas GoncalvesOrientador: Prof. Antonio Manuel Ferreira Rito da SilvaVogal: Prof. Bruno Emanuel da Graca Martins

Outubro 2015

Nenhum problema tem soluc~ao.

Fernando Pessoa

Agradecimentos

Agradeco a disponibilidade e orientacao do Professor Antonio Rito Silva, sem o qual este trabalho

nao seria possıvel. Agradeco o voto de confianca do Professor Manuel Portela. Agradeco a restante

equipa, Luıs, Tiago e Diego pela ajuda e prontidao. Agradeco a minha famılia e amigos pela paciencia

e apoio.

iii

Ambito

Dissertacao de mestrado produzida no ambito do projeto de investigacao ‘Nenhum Problema Tem

Solucao: Um Arquivo Digital do Livro do Desassossego’ (referencia PTDC/CLE-LLI/118713/2010), do

Centro de Literatura Portuguesa da Universidade de Coimbra e do IST/INESC-ID, Universidade de Lis-

boa, com a participacao da Biblioteca Nacional de Portugal. Projeto financiado pela FCT e cofinanciado

pelo FEDER, atraves do Eixo I do Programa Operacional Fatores de Competitividade (POFC) do QREN,

COMPETE: FCOMP-01-0124-FEDER-019715.

v

Abstract

The work produced in the context of this dissertation was about the conceptualization and implemen-

tation of search and recommendations for the Collaborative Digital Archive of the Book of Disquiet. The

search was intended to retrieve fragments based not only in the textual context, but also in the available

fragment’s metadata. A recommendation system was also the goal of this work, capable of identifying

user’s preferences and produce a set of recommended fragments of the user’s interest. The recommen-

dation system chosen was a content based recommendation system supported by vector space model

to convert fragments into vector of properties and infer the similarity between fragments and user’s pre-

ferences, through the cosine similarity. The search and recommendation system were integrated into

the archive, built with SpringMVC Framework and Fenix Framework.

Keywords

Search, Content-based Recommendation System, Vector Space Model, Fragments, Collaborative

Digital Archive, Book of Disquiet, Fernando Pessoa

vii

Resumo

O trabalho relatado nesta dissertacao tem como objetivo a conceptualizacao e implementacao

de pesquisas e recomendacoes no Arquivo Digital Colaborativo do Livro do Desassossego. Neste

pretende-se efetuar a pesquisa baseada no conteudo textual dos fragmentos do Livro do Desassos-

sego, assim como na informacao disponibilizada pela metadata dos fragmentos. Tambem se ambicio-

nava a criacao de um sistema de recomendacao capaz de reconhecer as preferencias do utilizador e

produzir um leque de fragmentos recomendados. A escolha recaiu sobre um sistema de recomendacao

baseado em conteudos suportado por vector space model para a modelacao dos fragmentos em veto-

res de propriedades e calculo da semelhanca por cosine similarity. A integracao foi efetuada no contexto

de uma aplicacao web construıda sobre a SpringMVC Framework e Fenix Framework que concretizava

o arquivo digital.

Palavras Chave

Pesquisa, Sistema de Recomendacao Baseado em Conteudos, Vector Space Model, Fragmentos,

Arquivo Digital Colaborativo, Livro do Desassossego, Fernado Pessoa

ix

Conteudo

1 Introducao 1

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Organizacao do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 State of The Art 5

2.1 Arquivo Digital Colaborativo do Livro do Desassossego . . . . . . . . . . . . . . . . . . . 6

2.2 Vector Space Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Sistemas de Recomendacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Baseados em Conteudos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.2 Filtros Colaborativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Contexto 21

3.1 Recolha de Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Informacao Disponıvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Descoberta de Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4 Informacao Gerada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Definicao do Problema 25

4.1 Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1.1 Pesquisa Simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1.2 Pesquisa Avancada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Recomendacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.1 Navegacao por Recomendacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.2 Ordenacao de Edicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.3 Criacao Automatica de Seccoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Interface Proposta 29

5.1 Interface proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 Pesquisa Simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3 Pesquisa Avancada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.4 Ordenacao de Edicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.5 Ordenacao Encaixada de Edicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

xi

6 Solucao 41

6.1 Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.1.1 Pesquisa Simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.1.2 Pesquisa Avancada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.2 Navegacao por Recomendacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.3 Ordenacao de Edicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.3.1 Ordenacao Encaixada de Edicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.4 Sistema de Recomendacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.4.1 Vetores de Preferencias do Utilizador . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.4.2 Vetores de Propriedades do Fragmento . . . . . . . . . . . . . . . . . . . . . . . . 46

7 Integracao no LodD 53

7.1 Modulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.2 Indexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.3 Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.3.1 Pesquisa Simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.3.2 Pesquisa Avancada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.3.2.A Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.3.2.B Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.4 Sistema de Recomendacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.5 Alteracoes ao Domınio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.5.1 Guardar as Preferencias do Utilizador . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.5.2 Adicionar Seccoes a Edicoes Virtuais . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.6 Navegacao por Recomendacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.7 Ordenacao de Edicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.8 Ordenacao Encaixada de Edicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8 Conclusao 73

8.1 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

8.2 Desenvolvimentos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Referencias 75

Apendice A Diagramas de classes A-1

Apendice B DML B-1

xii

Lista de Figuras

2.1 Diagrama de entidades do Livro do Desassossego (LdoD). . . . . . . . . . . . . . . . . . 8

3.1 Diagrama de classes do LdoD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1 Interface da pesquisa simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 Interface da pesquisa avancada com opcao de heteronimo . . . . . . . . . . . . . . . . . 32

5.3 Interface da pesquisa avancada com opcao de heteronimo e inclusao editorial . . . . . . 33

5.4 Interface da pesquisa avancada com opcao de inclusao editorial . . . . . . . . . . . . . . 34

5.5 Interface da pesquisa avancada com multiplas opcoes . . . . . . . . . . . . . . . . . . . . 35

5.6 Interface da pesquisa avancada com multiplas opcoes disjuntas . . . . . . . . . . . . . . 36

5.7 Interface antes da ordenacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.8 Interface depois da ordenacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.9 Interface antes da ordenacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.10 Interface depois da ordenacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1 Vetor de propriedades da inclusao nas edicoes de peritos . . . . . . . . . . . . . . . . . . 48

6.2 Vetor de propriedades das fontes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.1 Diagrama de camadas do Arquivo do Livro do Desassossego . . . . . . . . . . . . . . . . 54

7.2 Diagrama de camadas do Arquivo do Livro do Desassossego . . . . . . . . . . . . . . . . 55

7.3 Diagrama de sequencia da pesquisa avancada . . . . . . . . . . . . . . . . . . . . . . . . 58

7.4 Interface de pesquisas avancadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.5 Diagrama de classes do visitor abstrato . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.6 Diagrama de classes de implementacoes de opcoes . . . . . . . . . . . . . . . . . . . . . 60

7.7 Diagrama de classes da inclusao nas edicoes de peritos . . . . . . . . . . . . . . . . . . . 60

7.8 Diagrama de classes das fontes autorais manuscritas e datilografas . . . . . . . . . . . . 61

7.9 Diagrama de classes do Recommender . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.10 Diagrama de classes do VSMFragInterRecommender e VSMFragmentRecommender . . 63

7.11 Diagrama de classes de implementacoes das propriedades textuais e taxonomicas . . . 64

7.12 Diagrama de classes da StorableProperty . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.13 Diagrama de classes do sistema de recomendacao para edicoes virtuais . . . . . . . . . 66

7.14 Diagrama de entidades com as preferencias do utilizador . . . . . . . . . . . . . . . . . . 67

7.15 Diagrama de entidades com seccoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

xiii

7.16 Diagrama de interacao da ordenacao de edicoes . . . . . . . . . . . . . . . . . . . . . . . 69

7.17 Interface da ordenacao encaixada de edicoes . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.18 Diagrama de classes da ordenacao encaixada . . . . . . . . . . . . . . . . . . . . . . . . 70

7.19 Diagrama de interacao da ordenacao encaixada . . . . . . . . . . . . . . . . . . . . . . . 71

7.20 Interface da ordenacao encaixada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

A.1 Diagrama de classes das pesquisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-2

A.2 Diagrama de classes do Sistema de Recomendacao . . . . . . . . . . . . . . . . . . . . . A-3

B.1 DML dos pesos do utilizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2

B.2 DML das seccoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-2

xiv

Lista de Tabelas

2.1 Matriz de utilidade com as classificacoes de livros numa escala de 1 a 5. . . . . . . . . . 12

6.1 Vetores de propriedades de heteronimo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.2 Vetores de propriedades de data sem declınio . . . . . . . . . . . . . . . . . . . . . . . . 47

6.3 Vetores de propriedades de data com declınio . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4 Frequencia dos termos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.5 Vetores de propriedades textuais de F1 e F2 . . . . . . . . . . . . . . . . . . . . . . . . . 51

xv

Abreviacoes

LdoD Livro do Desassossego

TEI Text Encoding Initiative

XML Extensible Markup Language

HTML HyperText Markup Language

MVC Model–view–controller

JSP JavaServer Pages

VSM Vector Space Model

MVP Model-View-Presenter

MVC Model–View–Controller

JSON JavaScript Object Notation

SMART System for the Mechanical Analysis and Retrieval of Text

TF-IDF Term Frequency-Inverse Document Frequency

TF Term Frequency

IDF Inverse Document Frequency

k-NN k-Nearest Neighbors

DML Domain Modelling Language

xvii

1Introducao

Contents1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Organizacao do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1

1.1 Motivacao

O Livro do Desassossego (LdoD) e um projeto inacabado de Fernando Pessoa composto maiorita-

riamente por textos atribuıdos a Bernardo Soares, um dos seus heteronimos. O LdoD inclui cerca de

quinhentos textos escritos desde 1913 a 1935, ano em que faleceu.

No espolio de Fernando Pessoa encontramos varios rascunhos do LdoD nos quais esbocava a sua

visao do que seria este livro, enumerando os fragmentos que tencionava adicionar ao livro e qual a

ordenacao que pretendia fazer. Ate aos nossos dias, surgiram quatro edicoes crıticas do LdoD: Jacinto

Prado Coelho em 1982, Teresa Sobral Cunha em 1990-91, Richard Zenith em 1998 e Jeronimo Pizarro

em 2010.

A natureza das diversas edicoes crıticas esta longe de ser homogenea. O numero de fragmen-

tos incluıdos em cada edicao crıtica do LdoD diverge de edicao para edicao e cada edicao segue

princıpios proprios para a organizacao tematica e cronologica dos fragmentos [1]. As edicoes diver-

gem nos fragmentos que constituem o LdoD assim como na ordenacao dos fragmentos. As edicoes

tambem nao estao alinhadas quanto as transcricoes. Coelho e Pizarro optam por manter a ortografia

original, fazendo uma transcricao fiel a Fernando Pessoa, enquanto que Cunha e Zenith normalizam

as transcricoes. Os editores tambem nao se encontram em sintonia no que toca a atribuicao de he-

teronimo dos fragmentos. Coelho e Zenith atribuem todos os fragmentos a Bernardo Soares, no entanto

Teresa Sobral Cunha defende que alguns dos fragmentos sao de Vicente Guedes, outro heteronimo de

Fernando Pessoa.

O LdoD pode assim ser caracterizado como um conjunto de fragmentos autorais, de origem ma-

nuscrita, datilografada e impressa, que Pessoa nunca chegou a publicar, que foram transcritos, sele-

cionados e incluıdos em quatro edicoes crıticas, fazendo transparecer as multiplas vertentes crıticas e

geneticas do que podera ser uma interpretacao do LdoD [2].

O Arquivo LdoD surge como um repositorio que visa a dar a conhecer o LdoD nas suas multiplas

vertentes, incluıdo as digitalizacoes de todos os fragmentos assim como as respetivas interpretacoes

associados ao LdoD. Para alem de dar a conhecer o LdoD, tambem pretende dar ao utilizador a

possibilidade de colaborativamente compilar novas versoes do LdoD.

Neste documento iremos acompanhar a extensao do Arquivo LdoD para suportar outras formas

de navegacao pelo repositorio, atraves de um sistema de pesquisa capaz de recolher fragmentos que

satisfacam os criterios estabelecidos pelo utilizador e um sistema de recomendacao capaz de identificar

semelhancas entre fragmentos para sugerir ao utilizador.

1.2 Organizacao do documento

O documento encontra-se dividido em oito capıtulos. No proximo capıtulo iremos fazer uma sinopse

do que e o Arquivo LdoD, apresentar uma forma de representar as propriedades dos objetos atraves de

Vector Space Model (VSM) e apresentar um estudo bibliografico sobre sistemas de recomendacao. No

Capıtulo 3 sera feita uma analise do contexto do LdoD no qual apresentaremos a informacao disponıvel

em torno dos fragmentos que deverao ser usados para guiar a pesquisa e recomendacao, refletindo a

2

discussao que foi feita com a equipa do projeto LdoD. O Capıtulo 4 ira apresentar uma formalizacao das

funcionalidades dos sistemas de pesquisas e recomendacoes. O Capıtulo 5 introduz o conjunto de fun-

cionalidades a implementar, apresentado as interfaces que celebram este compromisso. No Capıtulo 6

teremos uma descricao da estrategia que ira guiar a implementacao das pesquisas e recomendacoes,

formalizando os conceitos de pesquisa e recomendacao no ambito do Arquivo LdoD. O Capıtulo 7 ira

relatar a implementacao das pesquisas e recomendacoes, e a respetiva integracao no Arquivo LdoD.

No ultimo capıtulo faremos um balanco do trabalho realizado face as expectativas da equipa do LdoD,

assim como apresentar os proximos passos a dar dentro das pesquisas e recomendacoes, indicando o

que podera ser feito face a evolucao do projeto.

3

4

2State of The Art

Contents2.1 Arquivo Digital Colaborativo do Livro do Desassossego . . . . . . . . . . . . . . . . 62.2 Vector Space Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Sistemas de Recomendacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5

O Capıtulo 2 apresenta uma reflexao bibliografica sobre o Arquivo Livro do Desassossego, Vector

Space Model e sistemas de recomendacao, estabelecendo um ponto de partida para a criacao do

sistema de pesquisas e recomendacoes.

2.1 Arquivo Digital Colaborativo do Livro do Desassossego

O Arquivo LdoD nasce com dois grandes objetivos, por um lado pretende ser uma ferramenta para

que especialistas consigam estudar o LdoD e comparar as diferentes interpretacoes dos fragmentos

que o compoem. Por outro lado, pretende desenhar um arquivo digital para que utilizadores interes-

sados na obra de Fernando Pessoa consigam explorar o espolio do LdoD e assumir o papel de editor

na construcao das suas edicoes [3]. Ao refinar a coexistencia destes dois conceitos produziu-se um

modelo dinamico que formaliza as quatro vertentes do Arquivo LdoD que sao reconciliados na vertente

de leitor, editor, livro e autor [2, 4].

Leitor

A vertente leitor tem como finalidade a preservacao da natureza dos fragmentos, proporcio-

nando ao utilizador uma visualizacao das diferentes interpretacoes do fragmento, conservando

a genetica das fontes autorais, assim como a visualizacao da apreciacao crıtica efetuada pelos

editores no decorrer da construcao das quatro edicoes. Para alem da visualizacao tambem se pre-

tende realcar as variacoes que caracterizam as interpretacoes dos varios testemunhos, variacoes

autorais encontram-se fontes autoriais manuscritas, datilografadas e impressas, e variacoes edi-

toriais introduzidas nas interpretacoes apresentadas pelas edicoes crıticas. Estas variacoes sur-

gem da apreciacao dos editores e resultam em correcoes ortograficas, alteracao de sinais de

pontuacao, conjeturas sobre passagens ilegıveis. As variacoes introduzidas pelas edicoes crıticas

nao se encontram cingidas ao conteudo textual, mas tambem as variacoes de data e heteronimo

que resultaram da apreciacao do editor ao longo da construcao das edicoes crıticas. Deste modo,

a vertente leitor alia os testemunhos de um fragmento com as multiplas variacoes estruturais que

o fragmento sofreu pelos varios atos de escrita e leitura.

Editor

O objetivo da vertente editor prende-se com a criacao de interpretacoes para os fragmentos do

LdoD. Estas interpretacoes sao produzidas pelos especialistas do projeto LdoD e possuem uma

natureza estatica. As interpretacoes sao codificadas seguindo o esquema Text Encoding Initiative

(TEI) [5], um conjunto de diretivas para a representacao digital de textos em Extensible Markup

Language (XML), que sao a base do arquivo digital. No ambito da vertente editor tambem se

pretende dar ao utilizador os meios para criar as suas edicoes virtuais do LdoD, permitindo que

este selecione os fragmentos a incluir nas suas edicoes e expresse a ordenacao tematica dos

fragmentos atraves da ordenacao da edicao. Para alem da informacao de natureza estatica,

tambem suporta a criacao de etiquetas e anotacoes para a classificacao de interpretacoes no

contexto de uma edicao virtual.

6

Livro

A vertente livro tem como proposito a reconstrucao do LdoD a partir de um conjunto de criterios

predefinidos. Nele encontraremos a pesquisa como uma forma de identificar fragmentos segundo

criterios de procura, iniciando uma edicao semantica onde todos os fragmentos respeitam essa

semantica. A edicao semantica resultante da pesquisa podera ser um ponto de partida para a

criacao de uma edicao virtual, A navegacao surge como outro aspeto da vertente livro, estabe-

lecendo uma forma de explorar o LdoD baseando-se num fragmento de contexto que define um

ponto de entrada para uma nova edicao do LdoD. A geracao automatica de novas edicoes do

LdoD a partir de um conjunto de criterios ira criar edicoes em que os fragmentos sao agrupados,

criando capıtulos e seccoes que obedecem a semantica dos criterios.

Autor

O proposito da vertente Autor tem como objetivo a producao de novos conteudos associados ao

LdoD. A natureza destes conteudos prende-se com a criacao, edicao e extensao de fragmentos

do LdoD. O utilizador pode assim elevar o seu papel ao nıvel de autor, em que tem acesso a

informacao do fragmento e conteudo textual para editar e rever, tendo a hipotese de modificar o

conteudo textual, heteronimo associado, data, notas, etc. A criacao de interpretacoes de fragmen-

tos existentes e a metodologia usada para incluir um fragmento numa edicao virtual do utilizador

e o fragmento estendido passa a ser um novo elemento do arquivo, permitindo que outros utili-

zadores o estendam e incluam nas suas edicoes virtuais complementando a vertente livro com a

vertente autor.

O contexto desta dissertacao recaira principalmente sobre a vertente livro do Arquivo LdoD, em que

pesquisas e recomendacoes serao complementarmente usadas para criar as funcionalidades descritas.

A conjugacao das varias vertentes do Arquivo LdoD geraram tres dimensoes de interacao entre

utilizadores e arquivo.

Genetica

A dimensao genetica conjuga as vertentes leitor e livro para recriar o processo de criacao do LdoD

por Fernando Pessoa. A vertente de leitor surge como uma forma de visualizar um fragmento de

um ponto de vista genetico, conservando as propriedades dos atos de escrita. A vertente livro tem

como finalidade a contemplacao de meios para efetuar as pesquisas sobre as edicoes geneticas

do LdoD.

Social

A dimensao social prende-se com a visao do repositorio construıda a partir da comunidade ins-

taurada em torno do LdoD, conjugando as quatro edicoes crıticas com textos crıticos e informacao

crıtica suplementar. O Arquivo LdoD torna-se assim um forum de trabalhos realizados em torno

do LdoD.

Virtual

A dimensao virtual engloba a criacao de novas apreciacoes do LdoD. Os utilizadores serao con-

7

vidados a editar e criar novas interpretacoes dos fragmentos no contexto das edicoes do LdoD

que irao compilar. As edicoes criadas no contexto virtual serao fruto do esforco individual de um

utilizador ou de comunidades construıdas em torno de uma edicao virtual onde varios utilizadores

colaboram para reinterpretar o LdoD, combinando a vertente autor e editor.

O modelo que pretende facilitar a existencia destes dois planos encontra-se presente na Figura 2.1.

O diagrama formaliza as relacoes entre o fragmento, fontes, interpretacoes e edicoes.

Figura 2.1: Diagrama de entidades do Livro do Desassossego.

Ate este ponto, usamos fragmento para descrever um texto escrito por Fernando Pessoa no ambito

do LdoD. A partir do diagrama de entidades apresentado em 2.1, temos o fragmento representado pela

classe Fragment, formalizando-o assim como uma agregacao de fontes e interpretacoes. Assim sendo

o fragmento deixa de representar um texto escrito por Fernando Pessoa, torna-se assim num ponto

de reconciliacao entre fontes e interpretacoes cuja semantica pretende representar um ato a incluir

no LdoD idealizado por Fernando Pessoa e toda a sua evolucao ate aos nossos dias. A fonte, neste

contexto passa a representar um ato de escrita efetuado por Fernando Pessoa em vida. A interpretacao

representa a apreciacao que foi efetuada num determinado ato de leitura, apresentando a evolucao do

fragmento. O fragmento per si nao tem nao contem informacao palpavel, sendo necessario viajar ate as

fontes e interpretacoes a que esta associado para o explorar na sua totalidade. Um exemplo claro desta

linha de pensamento e o heteronimo. Tal como apresentado na Figura 2.1, a atribuicao do heteronimo

e feita ao nıvel da interpretacao e nao ao nıvel do fragmento. Desta forma um fragmento pode ter varias

apreciacoes em que os heteronimos diferem, representando a realidade que se encontra nas varias

edicoes crıticas. O texto, que ate agora grosseiramente enderecamos por fragmento, encontra-se nas

interpretacoes do fragmento, deste modo um fragmento possui varias representacoes do seu conteudo

textual em cada uma das duas interpretacoes.

A classe Source representa as fontes autorais criadas por Fernando Pessoa. Esta e por sua vez

especializada para figurar as fontes manuscritas e datilografadas atraves da classe ManuscriptSource,

e na classe PrintedSource para representar as fontes publicadas ainda em vida.

8

As varias interpretacoes estao representadas pela classe abstrata FragInter. A interpretacao en-

carna uma apreciacao crıtica de um fragmento. A interpretacao e assim especializada em tres classes,

consoante o perfil da apreciacao. Uma interpretacao efetuada por um dos editores no contexto de

uma edicao crıtica, encontra-se materializada na classe ExpertEditionInter. A classe SourceInter de-

nota uma interpretacao feita pela equipa do projeto LdoD sobre as fontes autorais. Uma interpretacao

efetuada por um utilizador no contexto de uma edicao virtual encontra-se representada pela classe

VirtualEditionInter. O fragmento e assim uma composicao de fontes e interpretacoes.

As edicoes do LdoD representadas pela classe abstrata Edition e especializada em duas classes.

As edicoes crıticas estao comportadas nas ExpertEdition. A classe VirtualEdition evidencia as edicoes

criadas pelo utilizador, que e representado pela classe LdoDUser. De salientar a composicao de cada

um destes tipos de edicoes. A edicoes virtuais sao compostas por VirtualEditionInter e as edicoes

crıticas por ExpertEdtitionInter. As taxonomias conceptualizadas na vertente editor encontram-se aqui

representadas pela classe Taxonomy e as suas categorias pela classe Category, denotando a relacao

entre as categorias e as interpretacoes.

O modelo explicita as entidades do LdoD com o maior nıvel de granularidade e relevancia para o

trabalho a realizar nesta dissertacao. Este tambem representa parte das entidades que estao do modelo

de domınio construıdo e gerido pela FenixFramework [6]. A plataforma web e gerida pela framework

Spring MVC [7]. A interface web e construıda recorrendo ao uso da biblioteca jQuery [8] para gestao as

interacoes e o estilo ficou sobre a alcada do Bootstrap [9].

2.2 Vector Space Model

O Vector Space Model (VSM) [10] e apresentado pela primeira vez por Gerard Salton durante o

desenvolvimento do sistema de recolha de informacao System for the Mechanical Analysis and Re-

trieval of Text (SMART) [11]. O VSM pretende representar os elementos do domınio sob a forma de

vetores e calcular a semelhanca com o elemento de referencia atraves do angulo entre os dois vetores.

Desta forma consegue espelhar o grau de semelhanca entre elementos do domınio de forma concisa e

previsıvel.

Este processo e constituıdo por tres etapas: extracao, modelacao e classificacao dos elementos

de um domınio. Na primeira fase e feita a extracao das propriedades relevantes dos elementos do

domınio. Na segunda fase, a informacao extraıda e modelada para que seja representada sob a

forma de um vetor tendo nao so em conta a informacao extraıda mas tambem possıveis parametros

de configuracao. Na terceira fase, os vetores sao comparados com um vetor de referencia, obtendo-se

assim a classificacao dos elementos do domınio com o elemento de referencia.

Na pratica, nao e necessario calcular o angulo para determinar a semelhanca entre os vetores.

Esta simplificacao advem das propriedades do cosseno, onde vetores iguais, que possuem um angulo

de zero graus tem um cosseno com o valor 1, e vetores ortogonais, isto e, sem nada em comum

entre si, tem um angulo de noventa graus com um cosseno associado de 0. Vetores que expressem

propriedades opostas, isto e, tem um angulo de cento e oitenta graus entre si, apresentam um cosseno

9

cujo valor e -1. Assim sendo, o cosseno do angulo surge na literatura como a cosine similarity entre

dois vetores e e calculado a partir do quociente entre o produto escalar e o produto vetorial, tal como

apresentado em 2.1.

s(a, b) = cos θ =~va · ~vb~va × ~vb

=

∑i ~va,i~vb,i√∑

i(~va,i)2√∑

i(~vb,i)2

(2.1)

Coisine Similarity entre os itens a e b.

A semelhanca traduz assim o angulo entre dois vetores numa escala entre -1 e 1, no entanto, os

modelos de representacao usados para criar os vetores de propriedades representam-mas com valores

positivos, assim sendo, a cosine similarity varia entre 0 e 1.

Nesta estrategia, cada posicao do vetor representa uma propriedade que queremos usar para

comparacao e o valor nessa posicao indica a intensidade da propriedade. E nesta conjugacao de

intensidades que reside o desafio na modelacao da informacao para que seja representada sob um

vetor. Quando um objeto nao manifesta uma propriedade, a posicao do vetor que a representa, surgira

com o valor zero. Um valor diferente de zero indica a existencia da propriedade e o seu valor repre-

senta a intensidade da propriedade. Tambem e possıvel inflacionar a relevancia de uma propriedade

face as outras propriedades, multiplicando a sua intensidade por um gradiente maior que 1, assim como

e possıvel reduzir a relevancia de uma propriedade, multiplicando a sua intensidade por um gradiente

entre 0 e 1. Podemos neutralizar uma propriedade, isto e, torna-la irrelevante atraves da multiplicacao

da intensidade por 0. Os pares de zeros, ou seja, vetores que contenham zero na mesma posicao

podem ser ignorados pois em nada irao influenciar a semelhanca do cosseno, o seu papel no produto

escalar e no produto vetorial e irrelevante.

O VSM e usada para suportar sistemas de pesquisa, indexacao e recomendacao.

2.3 Sistemas de Recomendacao

O ato de recomendar e algo de familiar, inerente a natureza social e humana de partilha de ex-

periencias e conhecimento. A recomendacao num ambito social e tradicional tem como origem o grupo

de pessoas que nos rodeiam ou a opiniao de crıticos com as quais entramos em contacto. Livros,

musicas, carros, filmes, comida e uma mirıade de produtos e conteudos sao-nos recomendados e men-

cionados, sendo desta forma que tomamos conhecimento da sua existencia e conjeturamos o nosso

grau de interesse. Estas recomendacoes tanto podem ser obtidas atraves da consulta da opiniao de um

crıtico literario sobre a qualidade e interesse de um livro, ou sobre a forma de uma experiencia vivida

por alguem no cırculo de pessoas que nos rodeia, elogiando um livro, restaurante ou destino de ferias.

Este metodo de recomendacao dificulta a exploracao de novos conteudos, dado que a rede de recolha

e composta apenas pelo cırculo de pessoas e fontes crıticas de informacao. Qualquer conteudo que

nao entre em contacto com esta rede nunca podera ser recomendado e sera completamente ignorado.

Veremos que os conceitos abordados pelos sistemas de recomendacao seguem esta filosofia, esca-

lando a rede muito alem do que o cırculo de pessoas e crıticos conseguem recomendar para o universo

10

de todos os utilizadores e itens disponıveis na aplicacao.

A era da informacao aumentou consideravelmente o volume de produtos e conteudos ao nosso

dispor, tornando o ato de escolher bem mais complicados. O numero de itens sobre os quais refletir

e maior. No passado, a escolha era restringida pelos filmes em nossa posse, filmes disponıveis no

videoclube mais proximo e filmes que estejam a passar na televisao no serao de sexta feira. Neste

conjunto de fontes cinematograficas terıamos varias centenas de filmes para escolher. Atualmente,

os servicos de transmissao de filmes sao cada vez mais comuns e facilmente acessıveis, aumentado

exponencialmente o numero de filmes disponıveis. Netflix, um servico de transmissao de filmes e series,

disponibiliza mais de 17000 filmes [12].

Os sistemas de recomendacao surgem do aumento exponencial de conteudos. Esta area de es-

tudo tem o objetivo de prever o grau de interesse de um utilizador em conformidade com um elemento

do domınio, baseado nos interesses previamente expressados pelo utilizador. No entanto, o volume

de informacao e conteudo disponıvel na web aumenta a complexidade desta tarefa. Esta adversidade

torna-se evidente quando se passa do paradigma de uma loja fısica, que tem um espaco limitado e onde

apenas e possıvel expor uma quantidade limitada de produtos para o de uma loja virtual, capaz de con-

ter um numero quase ilimitado de artigos. Uma livraria apenas pode ter um numero limitado de livros

disponıveis para venda, por outro lado, a Amazon disponibiliza varios milhoes de livros. Assim sendo,

uma loja fısica tem de escolher quais os produtos que deseja expor. Por outro lado, a loja virtual nao

sofre esta restricao, podendo colocar produtos a venda sem correr o risco de ficar sem espaco na loja.

Esta diferenca gera o fenomeno long-tail [13] que retrata a diferenca entre a loja fısica e a loja virtual.

A loja fısica tera apenas os produtos mais procurados. Em contrapartida a loja virtual tera os produtos

mais procurados e uma mirıade de produtos muito menos procurados. Estes produtos menos procu-

rados constituem a long-tail. O uso de sistemas de recomendacao torna-se assim uma necessidade

no ambito de loja virtual, pois o paradigma tıpico de recomendacao duma loja e a listagem dos artigos

mais vendidos, nao sendo possıvel criar uma lista de livros recomendados especıfica para cada poten-

cial cliente. Uma livraria so pode apresentar os livros mais vendidos da semana ou mes. No entanto,

a dimensao de artigos disponıveis numa loja virtual inviabiliza esta abordagem, pois a recomendacao

dos artigos mais populares em nada contribuiria para promover os artigos menos procurados que se

encontram na long-tail.

Desta forma, o volume torna-se por si so um problema, a oferta passa a ser tanta que apresentar

todos os produtos disponıveis se torna impossıvel, sendo necessario determinar quais os produtos que

poderiam interessar ao utilizador, podendo assim expor os produtos mais interessantes para o utilizador,

aumentando a probabilidade de realizar uma venda ou consumir o conteudo.

Este fenomeno forca as lojas virtuais a focar a recomendacao em parametros mais restritos tentando

responder a pergunta, qual sera o grau de interesse de um utilizador num produto com o qual ainda

nao interagiu? Os sistemas de recomendacao surgem para dar resposta a esta pergunta e colmatar

a ausencia desta informacao atraves de previsoes, formalizando assim a previsao como sendo uma

conjetura do grau de interesse do utilizador por um dado item e uma recomendacao como um conjunto

de previsoes com um interesse elevado para o utilizador. A pergunta e transversal a todos os servicos

11

que pretendam aumentar a eficacia da selecao de conteudos e produtos a apresentar, tornando-se

numa ferramenta vital capaz de potenciar a satisfacao dos utilizadores e clientes.

Num sistema de recomendacao e necessario criar uma forma de representar a relacao entre os uti-

lizadores e os itens. Uma forma de representar esta classificacao e atraves de uma matriz de utilidade,

tal como demonstrado na Tabela 2.1.

A Game of Thrones A Clash of Kings A Storm of SwordsAndre 4 3 5Filipe 2 1

Tabela 2.1: Matriz de utilidade com as classificacoes de livros numa escala de 1 a 5.

Esta matriz apresenta duas dimensoes, com o proposito de espelhar as duas entidades envolvidas

no sistema de recomendacao, utilizadores e itens. Assim sendo uma dimensao apresenta os utilizado-

res e a outra dimensao os itens. Na intercecao entre as duas dimensoes reside a classificacao atribuıda

pelo utilizador ao item. De notar que esta matriz tera celulas vazias, indicando que um utilizador ainda

nao classificou o item. O objetivo do sistema de recomendacao e prever as classificacoes que um utili-

zador poderia dar a um item atraves da informacao disponıvel na matriz, e assim determinar o interesse

do utilizador. Neste caso em particular, prever qual a classificacao que o utilizador Filipe daria ao livro

A Storm of Swords.

A recolha de informacao para preencher a matriz de utilidade e o ponto de partida para dar inıcio

a producao de recomendacoes, pois a compilacao de recomendacoes sem a matriz de utilidade seria

quase impossıvel. A recolha de informacao e assim vital para o sistema de recomendacoes e pode ser

feita de duas formas.

Explıcita

A colecao de classificacoes pode ser feita de forma explıcita, facultando ao utilizador meios para

classificar os itens. Por exemplo, solicitando ao utilizador que classifique o item apresentado numa

escala de 1 a 5 ou indicando que gostou do item. Esta classificacao e depois transposta para a

matriz de utilidade. A eficacia desta abordagem e limitada, pois esta dependente da cooperacao

dos utilizadores e da sua vontade em classificar os itens.

Implıcita

Em contrapartida a classificacao implıcita tem como objetivo gerar uma classificacao atraves da

monitorizacao do comportamento dos utilizadores, verificando se estes demonstram especial in-

teresse num item. Este interesse pode ser manifestado atraves do tempo despendido a ler uma

notıcia, visualizacao de um vıdeo do princıpio ao fim ou comprar um produto. Nestas interacoes o

utilizador expressa implicitamente o seu interesse nos itens e estes indicadores sao usados para

preencher a matriz de utilidade.

A producao de previsoes pode ser suportada a partir de duas formas de modelacao da informacao

disponıvel. Por um lado temos os algoritmos baseados em memoria, que se focam em tecnicas retiradas

da recolha de informacao para efetuar uma previsao a partir do calculo da utilidade atraves de uma

formula heurıstica, como a cosine similarity. A motivacao por detras do seu uso prende-se com a

12

precisao da previsao e simplicidade da implementacao. As previsoes mantem-se coerentes com os

objetos do domınio, pois analisam todos os itens e/ou utilizadores na producao de uma recomendacao.

Em contrapartida, este ultimo ponto apresenta problemas de escalabilidade quando e expectavel que o

numero de itens e/ou utilizadores aumente.

Por outro lado temos as abordagens baseadas no modelo que pretendem inferir a previsao atraves

da aprendizagem do domınio e construcao de um modelo de previsoes. O uso de algoritmos base-

adas no modelo tem como principal objetivo evitar o uso de todos os itens do domınio para efetuar

uma previsao. O reconhecimento do domınio e feito atraves do uso de metodos probabilısticos, como

por exemplo classificacao bayesiana ou recorrendo a algoritmos de aprendizagem como redes neu-

ronais artificiais, arvores de decisao ou clustering. Apesar de resolver o problema de escalabilidade

dos algoritmos baseados em memoria, criam novos desafios na adicao de novos objetos ao domınio,

pois e necessario treinar o modelo para recomenda-los e a coerencia entre a previsao e domınio esta

altamente depende da qualidade da aprendizagem.

2.3.1 Baseados em Conteudos

A estrategia quase intuitiva para ser usada num sistema de recomendacao e a identificacao de itens

que agradem ao utilizador atraves da observacao das propriedades dos itens e o interesse demonstrado

pelo utilizador sobre essas propriedades. Este ramo dos sistemas de recomendacoes e classificado

como baseados em conteudos, pois foca-se inteiramente nas propriedades dos itens e utilizadores

para produzir recomendacoes.

Inerente a esta formulacao temos tres desafios a resolver para produzir recomendacoes. Identificar

as propriedades dos itens, identificar das preferencias dos utilizadores e determinar a recomendacao

atraves do grau de semelhanca entre as propriedades e preferencias.

A identificacao das propriedades pode basear-se nas caraterısticas dos itens que se pretendem

recomendar, isto e, usar a informacao do item que e capaz de o descrever como ponto de comparacao.

A descricao de um livro pode ser feita atraves da identificacao do seu autor e genero. Um filme pode ser

descrito a partir do ator principal, argumentistas, genero e diretor. Uma musica pode ser identificada

por grupo, album, compositor e estilo. A partir das propriedades temos uma base que pode ser usada

para identificar o grau de semelhanca entre os itens.

No entanto e possıvel expandir o conceito de propriedade para alem das caracterısticas que pode-

mos identificar imediatamente nos itens. A expansao torna-se necessaria quando estamos na presenca

de itens que nao comportam informacao adicional. Uma imagem e somente um conjunto de bits cuja

informacao adicional e pouco rica, incapaz de ser usada como propriedades. O uso de etiquetas surge

como uma alternativa capaz de enriquecer as imagens. As etiquetas enriquecem a imagem com pro-

priedades que nao seria possıvel extrair da imagem por si so. O uso de etiquetas nao se limita apenas

a imagens e pode ser aplicado a qualquer tipo de item, tanto para colmatar a ausencia de metadados

capazes de descrever o item em propriedades como para completar a descricao do item para alem do

que seria possıvel com a sua informacao.

A estrategia para a obtencao das etiquetas pode ter varias origens. Ao submeter uma nova questao

13

no Stackoverflow [14], e pedido ao utilizador que introduza ate 5 palavras que descrevam o ambito do

problema e irao etiquetar a questao. Em contrapartida, Wallhaven [15] permite a qualquer utilizador

registado adicionar e remover etiquetas de uma imagem. Ainda no capıtulo da etiquetagem de itens

temos a abordagem do Phetch [16] em que se etiquetam recorrendo a um jogo. O jogo conta com

a participacao de 3 a 5 jogadores, no qual um assume o papel de Describer e tem como objetivo

descrever a imagem que lhe e apresentada. Os outros jogadores, desempenhando o papel de Seekers,

tem o objetivo encontrar a imagem apresentada ao Describer, efetuando pesquisas textuais. Assim

sendo, o jogo consegue encontrar novos termos introduzidos pelos Seekers para descrever as imagens

ao seu dispor. O jogo proporciona entretenimento em troca de processamento humano, ao mesmo

tempo que cativa o utilizador. Ao proporcionar entretenimento faz com que os utilizadores de boa

vontade classifiquem os itens da aplicacao, um dos problemas da recolha de explıcita de classificacoes.

Por outro lado os conjuntos de textos, comuns na web, como entradas de blogues ou comentarios

em foruns tambem sao pouco ricos em informacao que pode ser usada para extrair propriedades. Estes

tambem podem ser classificacoes recorrendo a etiquetas capazes de descrever o texto num conjunto

de propriedades. No entanto podemos recorrer ao conteudo do texto para identificar.

A analise do texto tem como objetivo extrair um perfil do texto capaz de descrever os topicos do texto.

O metodo de estatıstico de analise de texto Term Frequency-Inverse Document Frequency (TF-IDF)

parte de um pressuposto de que as palavras mais frequentes do documento e muito pouco frequentes

em toda a colecao de textos sao as que melhor capturam a identidade do texto e descrevem as suas

caraterısticas principais. O calculo das palavras que melhor descrevem o texto envolve o calculo do

Term Frequency (TF), ou seja, o numero de vezes que a palavra aparece no texto. A fracao TF calcula

a relevancia de uma palavra para aquele texto. Tambem calcula o Inverse Document Frequency (IDF),

isto e, o inverso da frequencia do numero de textos em que o termo esta presente. Esta fracao e

responsavel por reduzir o TF-IDF de palavras que estao presentes em muitos textos, pois estas palavras

sao pouco descritivas de um texto em particular. Assim sendo, as palavras que melhor descrevem um

texto sao aquelas que aparecem muitas vezes num pequeno conjunto de textos. O calculo do TF-IDF

pode seguir varias formulas. No sistema de recomendacao de artigos sobre bricolage, PRES [17], o

calculo do TF-IDF segue a Formula 2.2.

tfidfi,D = tfi,D · log(n

dfi) (2.2)

TF-IDF com frequencia absoluta.

Por outro lado, tambem se pode efetuar uma dupla normalizacao dos TF, apresentado pela Formula 2.3,

como sugerido no recomendacao de topicos de foruns, apos identificar os termos mais frequentes se-

guindo a Lei de Zipf e remocao dos 100 termos mais frequentes [18].

tfidfi,D = (0, 5 + 0, 5 ∗ tfi,D) · log(n

dfi) (2.3)

TF-IDF com dupla normalizacao.

14

Tomando o exemplo de um jornal online de notıcias, as palavras que irao obter um valor mais alto de

TF-IDF serao aqueles que melhor descrevem as singularidades da notıcia, como por exemplo, o local,

motivo da notıcia e pessoas envolvidas.

Apos identificar a relevancia das palavras para identificar um texto, as palavras relevantes mais

comuns , isto e, com um valor mais alto de TF-IDF sao usadas para efetuar a comparacao entre textos.

O sistema FAB [19] usa os 100 termos com valor mais alto de TF-IDF para descrever o topico central

do texto.

A determinacao das preferencias dos utilizadores e o proximo passo para produzir recomendacoes.

As preferencias do utilizador sao determinadas de forma a conseguir exprimir um conjunto de pro-

priedades dos itens. Uma preferencia representa assim uma propriedade do utilizador, havendo um

mapeamento de um para um entre preferencias e propriedades. As preferencias do utilizador podem

ser determinadas facultando os meios necessarios para que o utilizador consiga expressar o seu in-

teresse em propriedades do domınio. Por outro lado, tambem se pode construir as preferencias do

utilizador atraves da observacao do seu comportamento para com os varios itens, procurando padroes

de interacao. Assim sendo, pretende-se colecionar as preferencias de utilizador a partir das proprieda-

des dos itens mais visitados.

A identificacao das preferencias de novos utilizadores constituı um desafio para sistemas onde a

identificacao feita atraves da observacao dos itens com que o utilizador interage. Enquanto o utilizador

nao interagir com um numero substancial de itens, o sistema sera incapaz de produzir recomendacoes

que estejam completamente alinhadas com as suas preferencias. Este problema pode ser mitigado,

permitindo ao utilizador selecionar um conjunto de propriedades que descrevam o seu interesse como

ponto de partida e modelar estas preferencias ao longo tempo para refletirem o comportamento de-

monstrado pelo utilizador.

A producao de uma previsao referente ao nıvel de interesse de um utilizador sobre um item esta

agora dependente da relacao entre as preferencias do utilizador e as propriedades dos itens. A cosine

similarity oferece meios para efetuar esta relacao atraves da modelacao das preferencias e proprieda-

des em vetores. Desta forma temos um vetor de preferencias, representando os gostos do utilizador e

um vetor de propriedades, representando as caracterısticas do item. As propriedades representadas

nos vetores podem ser as caracterısticas do item, as etiquetas atribuıdas ao item ou ainda o conjunto

de palavras mais relevantes extraıdo atraves do TF-IDF. A selecao de propriedades do vetor devera ser

a intercecao entre preferencias do utilizador e propriedades dos itens, pois e fundamental que ambos

os vetores tenham exatamente a mesma dimensao. A construcao do vetor tem por base o conjunto de

preferencias e propriedades, no qual cada posicao do vetor tem uma semantica bem definida. No vetor

de preferencias do utilizador os valores presentes representam o grau de interesse do utilizador por

aquela propriedade. No vetor de propriedades de um item temos o valor que representa a intensidade

da presenca do propriedade no item. O calculo do cosseno do angulo ira indicar o quao alinhados

estao os gostos do utilizador e as propriedades dos itens. O cosseno do angulo representa assim o

grau de interesse de um utilizador sobre um item numa escala de -1 a 1, onde 1 significa que esta muito

interessado, ou seja, os vetores estao sobrepostos e todas as propriedades do item satisfazem as pre-

15

ferencias do utilizador. O valor -1 para cosseno do angulo representa um item que tem propriedades

completamente opostas ao que o utilizador prefere.

A natureza da recomendacao baseada em conteudos, altamente focada nas propriedades dos itens

e preferencias dos utilizadores, tornando esta abordagem incapaz de produzir recomendacoes ines-

peradas, que estejam fora do espetro de interesses apresentado pelo utilizador. Este fenomeno e

denominado por super especializacao [20] na literatura referente a sistemas de recomendacao basea-

dos em conteudos. Esta propriedade pode ser vista como um problema, pois torna a recomendacao

demasiado tendenciosa e ira limitar a descoberta de novos itens dentro do espetro de interesses do

utilizador, nao sendo possıvel recomendar itens fora do espetro que podem tambem ser do interesse

do utilizador sem romper com o algoritmo tradicional. Serendipity e o nome dado as abordagens que

pretendem introduzir variacoes a recomendacao para que os itens apresentados pela recomendacao

sejam do interesse do utilizador, mas que estejam foram do seu espetro de interesses com o proposito

de aumentar a diversidade das recomendacoes. O nome pretende refletir a ideia de recomendacao

inesperada, mas afortunada. As variacoes podem ser atingidas por meio algoritmos geneticos que

pretende identificar um intervalo que se situa fora do espetro de interesses do utilizador determinado

pelo sistema de recomendacao, mas que continuam a ser relevantes para o utilizador. Esta abordagem

afina o intervalo de interesses do utilizador ao longo de varias iteracoes, tal como apresentado pelo as-

sistente pessoal Newt [21]. Outra estrategia e o uso de recomendacoes que focam as recomendacoes

em itens com semelhancas entre valores com maior probabilidade de estarem fora do espetro de pre-

ferencias do utilizador, isto e, que nao estejam inteiramente alinhados com os seus gostos, ignorando

aqueles que estao inteiramente alinhados com as preferencias do utilizador [20].

2.3.2 Filtros Colaborativos

As recomendacoes baseadas em conteudos focam a recomendacao nas propriedades dos itens que

pretende recomendar, sendo necessario criar uma semantica para as propriedades que se comparam,

sejam elas caraterısticas dos itens ou taxonomias associadas. Por outro lado, as recomendacoes ba-

seadas em filtros colaborativos focam a recomendacao na semelhancas entre a relacao demonstrada

pelos utilizadores e os itens da aplicacao sem refletir sobre as propriedades dos itens. Em vez de se

basear na semelhanca entre o vetor de propriedades que representa as caracterısticas de um objeto e o

vetor de preferencias que representa o perfil do utilizador, esta abordagem foca-se na relacao expressa

pelo utilizador com um objeto do domınio atraves do grau de interesse que este demonstrou pelo objeto.

O interesse pode ter uma origem explıcita, atraves da recolha de classificacoes providenciadas pelo

utilizador ou implıcita, registando a atividade do utilizador e identificando picos de atividade que revelem

o seu interesse.

Sendo assim, o objetivo desta abordagem e prever a classificacao que um utilizador daria a um

item antes de interagir com o item atraves da identificacao de utilizadores que deram classificacoes

semelhantes as classificacoes do utilizador para itens que ambos classificaram. A representacao das

classificacoes dos utilizadores e feita com o auxılio de uma matriz de utilidade. A consequencia ime-

diata desta abordagem e a incapacidade de produzir recomendacoes sem que haja um historial de

16

interacoes de utilizadores e itens, isto e, a matriz ainda nao possui um numero substancial de celulas

preenchidas para a producao de recomendacoes, denominado por cold start [22]. Este problema e miti-

gado atraves do recurso a sistemas baseados em conteudos capazes de produzir recomendacoes com

base nas propriedades dos itens, quando ainda nao existe uma base de interacoes para a producao de

recomendacoes baseadas em filtros colaborativos.

A filtragem colaborativa apresenta uma barreira para a adicao de novos utilizadores, pois as recomendacoes

sao baseadas nas classificacoes que se encontram na matriz de utilidade, isto e, as suas preferencias.

Enquanto que o utilizador nao classificar itens suficientes para identificar outros utilizadores semelhan-

tes a si, as previsoes nao serao as mais precisas. Este problema pode ser contornado atraves do uso

de recomendacoes baseadas em conteudos que consigam determinar o perfil do utilizador e produzir

recomendacoes atraves das propriedades dos itens disponıveis [23].

Tambem oferece uma barreira de entrada para novos itens, porque a relevancia de um item para

a recomendacoes depende das classificacoes que ja obteve. Enquanto nao for classificado por um

numero substancial de utilizadores, o sistema nao conseguira recomenda-lo. Esta adversidade pode ser

mitigada com a introducao de recomendacoes baseadas em conteudos capazes de determinar o grau

de semelhanca com itens existentes [23], pois a natureza da recomendacao baseada em conteudos

nao apresenta uma barreira a introducao de novos itens quando estes possuem informacao capaz de

ser usada para descrever o item atraves de propriedades.

As recomendacoes podem ser feitas utilizador a utilizador tal como apresentado no sistema de

recomendacoes para artigos da Usenet, GroupLens [24]. Esta abordagem e tambem referenciada

como k-Nearest Neighbors (k-NN) e e uma implementacao direta dos conceitos base da filtragem co-

laborativa, identificar os utilizadores mais parecidos com o utilizador e usar as classificacoes de itens

para determinar se o utilizadores ira gostar do item em questao Assim sendo, tem como objetivo encon-

trar os vizinhos k mais semelhantes com o utilizador. De seguida preve a classificacao que o utilizador

daria a um item que ainda nao classificou atraves da combinacao da semelhanca com o vizinho e as

diferencas das classificacoes. O calculo da vizinhanca pode ser efetuado atraves da cosine similarity,

ındice de Jaccard ou pelo coeficiente de correlacao de Pearson entre os utilizadores.

O ındice de Jaccard calcula a relacao entre utilizadores, identificando o numero de itens que os

utilizadores classificaram da mesma forma face ao numero de total de itens classificados pelos utiliza-

dores. Na Formula 2.4 temos ru como o vetor de classificacoes do utilizador u e rv como o vetor de

classificacoes do utilizador v. O ındice e assim o racio entre a dimensao da intersecao dos vetores

de classificacoes e a dimensao da uniao dos vetores de classificacoes. Quanto mais proximo de 1 se

encontra este racio, maior e a semelhanca entre os utilizadores.

s(u, v) =|ru ∩ rv||ru ∪ rv|

(2.4)

Indice de Jaccard entre os itens u e v.

O coeficiente de correlacao de Pearson, apresentado pela Formula 2.5, denota a semelhanca en-

tre utilizadores atraves do padrao de classificacao dos utilizadores. Tal como a cosine similarity, a

17

semelhanca entre u e v e calculada a partir do quociente entre o produto escalar, e o produto vetorial

dos vetores de classificacao dos utilizadores, ru e rv. Diverge da cosine similarity, pois a a media de

classificacoes do utilizador, ru e rv, for subtraıdo a cada posicao do vetor, ru,i e ru,i. A subtracao da

media de classificacoes normaliza as classificacoes do utilizador, neutralizando a sua propensao em

tomar uma classificacao como referencia a partir da qual classifica os itens.

s(u, v) =

∑i∈Iu∩Iv (ru,i − ru)(rv,i − rv)√∑

i∈Iu∩Iv (ru,i − ru)2√∑

i∈Iu∩Iv (ru,i − rv)2

(2.5)

Coeficiente de correlacao de Pearson entre os itens u e v.

O ındice de Jaccard traduz a semelhanca entre os utilizadores num ındice entre 0 e 1. Por outro

lado o coeficiente de correlacao de Pearson traduz a semelhanca entre os utilizadores num ındice entre

0 e 1.

A recomendacao utilizador a utilizador apresenta problemas de escalabilidade quando o numero

de utilizadores aumenta. O desafio reside na identificacao dos vizinhos mais proximos, pois este tem

de ser calculado com alguma frequencia. Sempre que o utilizador altera a classificacao de um item,

tambem esta a alterar toda a sua vizinhanca, sendo necessario identificar os seus novos vizinhos. Em

aplicacoes onde o numero de utilizadores e em varias ordens de grandezas superior ao numero de

itens disponıveis, o calculo frequente da vizinhanca torna-se um esforco consideravel.

Em contrapartida, a filtragem colaborativa item a item [25] altera o foco da recomendacao. Na

recomendacao utilizador a utilizador, esta e feita a partir da identificacao da vizinhanca de um utilizador

e prevendo a classificacao que o utilizador daria a um item com o qual ainda nao interagiu, a partir

das classificacoes dos seus vizinhos. A recomendacao item a item e feita a partir do item atraves da

identificacao de itens com classificacoes semelhantes. Esta parte do princıpio que os itens sao seme-

lhantes se tiverem classificacoes semelhantes para um vasto conjunto de utilizadores, pois e expetavel

que os utilizadores semelhantes possuam preferencias semelhantes. De certo modo, e semelhante a

recomendacoes baseadas em conteudos em que as propriedades sao as classificacoes dos utilizado-

res. Graficamente, esta abordagem compara as semelhancas entre as colunas da matriz de utilidade

em vez de comparar as linhas como e efetuado na filtragem colaborativa utilizador a utilizador.

A filtragem item a item e a mais usada, pois consegue contornar os problemas de escalabilidade

da filtragem colaborativa utilizador a utilizador [12]. Em aplicacoes em que o numero de utilizadores e

muito maior que o numero de itens, a identificacao de itens semelhantes processa o domınio mais pe-

queno. Esta mudanca de plano permite tirar partido da diferenca de volume entre os utilizadores e itens,

pois a procura de itens semelhantes ira recair sobre classificacoes menos volateis. A recomendacao

utilizador a utilizador tem o potencial para ser extremamente volatil, pois a alteracao de classificacoes

resultarao na necessidade de recalcular a vizinhanca do utilizador para gerar novas recomendacoes.

Por outro lado, numa aplicacao com muito mais utilizadores que itens, a alteracao de classificacoes por

parte do utilizador nao tera impacto na semelhanca entre itens, especialmente quando um item ja foi

classificado por muitos utilizadores. Esta estabilidade permite a computacao das semelhancas e man-

ter as recomendacoes precisas quando existem mudancas de classificacoes, sendo apenas necessario

18

recalcular as semelhancas quando for mais oportuno, por exemplo, durante perıodos de pouca carga.

Mais uma vez, o calculo da semelhanca entre itens pode ser feito atraves do coeficiente de correlacao

de Pearson ou a cosine similarity, sendo este ultimo o mais popular [12]. A Amazon ja tirou partido desta

propriedade no passado implementando filtragem colaborativa recorrendo a cosine similarity para iden-

tificar itens semelhantes [26].

Na recomendacao atraves de filtragem colaborativa tambem e comum o uso de tecnicas de clusterig

para agrupar utilizadores e/ou itens, reduzindo a dimensao da matriz e tornando mais escalavel com

o aumento de utilizadores e itens. Tambem ajuda a mitigar a tarefa de gerar recomendacoes a partir

de uma matriz de utilidade esparsa, isto e, com pouca informacao. Tanto os itens como os utilizadores

podem ser agrupados atraves do seu grau de semelhanca, calculado a partir do ındice de Jaccard,

cosine similarity ou coeficiente de correlacao de Pearson. Este processo pode ser repetido ate obter

um numero de clusters desejado. Uma nova matriz de utilidade pode assim ser criada com os clusters

de utilizadores e itens. A recomendacao passa agora por identificar os clusters do utilizador e do item.

Se os clusters ja estiverem classificados, nenhum calculo sera necessario para identificar o grau de

interesse do utilizador pelo item. Caso este se encontre em branco, o grau de interesse tera de ser

calculado.

Atraves da aplicacao de clustering a matriz torna-se menos esparsa, aumentado a probabilidade

de ter uma classificacao disponıvel, nao sendo preciso prever o interesse do utilizador. Caso seja

necessario prever, a previsao gerada entre os clusters nao se encontra desfasada da previsao entre os

itens do cluster [27].

�

As caraterısticas do Arquivo LdoD irao influenciar o sistema de recomendacao a adotar pela aplicacao.

Um sistema de recomendacao baseado em filtros colaborativos sao indicados para aplicacoes com um

elevado numero de utilizadores e itens, pois a precisao da recomendacao esta intrinsecamente depen-

dente do volume de interacoes entre utilizadores e itens. O nicho que e o Arquivo LdoD espera um

numero de utilizadores e itens incapaz de rivalizar com Youtube, Netflix ou Amazon. Sem um numero

elevado de utilizadores e itens, a diversidade de interacoes entre utilizadores e fragmentos seria com-

prometida, que por sua vez prejudicariam a geracao de recomendacoes.

Por outro lado a abordagem baseada em conteudos esta dependente da metadata associada aos

itens do domınio da aplicacao. Esta abordagem implicaria uma analise dos fragmentos do arquivo,

identificando e demarcando a metadata que poderia suportar um sistema de baseado em conteudo.

O algoritmo a selecionar para a producao de recomendacoes esta nao so dependente da tecnica

de recomendacao a usar, mas tambem da dimensao do sistema de recomendacao. A escolha entre

uma abordagem baseada em memoria ou no modelo esta altamente ligado ao numero de utilizadores e

itens da aplicacao. O arquivo possui mais de 500 fragmentos codificados e e expectavel que o numero

de fragmentos se mantenha por estes numeros. O baixo volume de utilizadores e itens permite o uso

de todos os itens na previsao de recomendacoes, nao justificando a criacao de um modelo predicativo

capaz de deduzir o interesse do utilizador, assim sendo, a abordagem baseada em memoria e candidato

privilegiado. A cosine similarity e o algoritmo mais frequente na literatura para a concretizacao de

19

sistemas de recomendacao baseados em memoria.

20

3Contexto

Contents3.1 Recolha de Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 Informacao Disponıvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3 Descoberta de Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 Informacao Gerada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

21

Neste capıtulo sera apresentado o contexto do LdoD, evidenciando a informacao referente aos frag-

mentos e interpretacoes do Arquivo LdoD que sera usada nas pesquisas e recomendacoes

3.1 Recolha de Informacao

O ambito do trabalho relatado ao longo desta dissertacao insere-se na vertente livro e e transversal

as tres dimensoes apresentada na Seccao 2.1. Neste capıtulo faremos uma analise sobre a informacao

referente aos fragmentos que pode ser usada tanto para demarcar criterios de pesquisa como para su-

portar as recomendacoes, refletindo a discussao que foi feita com a equipa do projeto LdoD. A paridade

entre estas duas funcionalidades vai alem da informacao sobre a qual irao operar, pois apresentam-se

com uma dualidade na exploracao de um meio, podendo ate ser usados em conjunto para afinar a

relevancia de um conjunto de resultados da pesquisa pela ordem de preferencia do utilizador. Esta

pratica e usada pelo motor de busca da Google [28].

O mote para orientar a identificacao de informacao nos fragmentos foi introduzido na Seccao 2.3.1,

onde postulamos tres formas de procurar e extrair informacao de itens do domınio para a producao

de recomendacoes. O domınio do LdoD serao os fragmentos que agregam informacao nas diver-

sas interpretacoes que o compoem. Assim sendo, analisaremos a informacao disponibilizada nas

interpretacoes a partir da sua codificacao no formato TEI, informacao que podemos descobrir a partir

da sua analise e ainda informacao que ira enriquecer os fragmentos do LdoD atraves da dimensao

virtual da aplicacao.

Figura 3.1: Diagrama das que que irao interagir com a pesquisa e recomendacoes.

22

3.2 Informacao Disponıvel

Os fragmentos codificados sobre o formato TEI possuem informacao adicional referente a si, ma-

terializado sobre as multiplas interpretacoes. Os indicadores que sao intuitivamente mais evidentes

que encontramos nas interpretacoes sao o heteronimo que se encontra atribuıdo e a data em que

se acredita que foi escrito. Uma interpretacao pode estar atribuıda a qualquer um dos heteronimos

identificados no Arquivo LdoD. Este grupo de heteronimos contem o heteronimo nulo com o intuito

de indicar interpretacoes que nao se encontram atribuıdas. A data segue o mesmo modelo, uma

interpretacao pode estar datada ou por datar. Para alem destes dois indicadores transversais a todas

as interpretacoes, tambem a propria natureza da interpretacao revela a existencia de uma interpretacao

sobre um meio. As interpretacoes de peritos revelam a inclusao numa edicao crıtica enquanto que as

interpretacoes de fonte revelam a existencia de fontes de um determinado tipo. As interpretacoes da

fonte contem informacao referente a genetica, podendo ser manuscrito, datilografado ou impresso numa

publicacao. Nas fontes, para alem de encontramos a data, encontramos ainda a marca LdoD, usada

por Pessoa para explicitar a intencao de adicionar o fragmento a sua edicao do LdoD.

Do mesmo modo, as interpretacoes que se encontram nas edicoes dos peritos tambem revelam

atraves da sua heterogeneidade a opiniao crıtica do que constitui o LdoD, sendo possıvel formalizar

o LdoD apenas com os fragmentos que estao incluıdos em todas as edicoes crıticas. De notar que

as interpretacoes retratam uma visao crıtica do fragmento, como tal esta disparidade devera ser aco-

modada tanto nas pesquisas como nas recomendacoes. As interpretacoes dos peritos contem ainda

informacao crıtica sobre a datacao e heteronimidade do fragmento, existindo a hipotese de refinar o

LdoD como sendo composto por todos os fragmentos que se encontram nas edicoes crıticas com

informacao homogenea segundo um destes marcadores ao longo das quatro edicoes crıticas.

A Figura 3.1 resume as relacoes e atributos que serao o foco da pesquisa e recomendacoes.

3.3 Descoberta de Informacao

A descoberta e extracao de informacao e apresentada na Seccao 2.3.1 como uma metodologia

para identificar a tematica de um texto e a partir dela, identificar textos com uma tematica semelhante.

Uma parte substancial dos fragmentos e o conteudo textual das varias interpretacoes, representado na

Figura 3.1 pela classe TextPortion. A extracao do tema de um fragmento a partir dos textos das suas

interpretacoes pode ser usada para orientar as recomendacoes. A informacao textual tambem e um

dos focos da pesquisa, sendo ela o meio sobre o qual se efetua a pesquisa textual.

3.4 Informacao Gerada

A informacao gerada surge na justaposicao entre informacao disponibilizada sob o formato TEI e a

contınua interacao entre utilizadores e fragmentos no contexto do arquivo colaborativo. O arquivo faculta

duas formas que permitem aos utilizadores expressar a sua visao do LdoD, atraves da construcao de

edicoes virtuais com os fragmentos que constituem o LdoD segundo a sua visao da obra e atraves

23

da criacao taxonomias que irao etiquetar as suas interpretacoes virtuais no contexto de um edicao

virtual. Consequentemente, as edicoes virtuais facultam uma forma de conceptualizar o LdoD, uma

funcionalidade analoga ao exercıcio realizado pelos editores na construcao das suas edicoes crıticas.

A demarcacao dos fragmentos com etiquetas evidencia uma propriedade do fragmento no contexto da

edicao virtual e surge tanto como uma forma de evidenciar como relacionam fragmentos, podendo ser

usada na pesquisa e recomendacao.

24

4Definicao do Problema

Contents4.1 Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2 Recomendacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

25

O Capıtulo 4 tem como objetivo explicitar o problema e formalizar as funcionalidades que se preten-

dem adicionar no ambito da vertente livro do Arquivo do LdoD.

4.1 Pesquisa

Pretende-se agora implementar um mecanismo que possibilite a pesquisa de fragmentos e interpretacoes

do LdoD, tal como apresentado na vertente livro e descrito na Seccao 2.1, facilitando assim o acesso

a fragmentos e interpretacoes com informacao de especial interesse para o utilizador. O Arquivo do

LdoD devera proporcionar ao utilizador a possibilidade de pesquisar fragmentos cujas interpretacoes

incluam um conjunto de palavras-chave, denominada de pesquisa simples. Tambem devera facultar

meios para pesquisar com base em criterios que o utilizador pode compor e parametrizar, obtendo as-

sim fragmentos com interpretacoes que satisfacam os criterios, a esta pesquisa chamaremos pesquisa

avancada.

4.1.1 Pesquisa Simples

A pesquisa simples devera ser a forma mais direta de pesquisar, permitindo ao utilizador procurar

por fragmentos que possuam pelos uma interpretacao com um conjunto de palavras-chave do seu

interesse. O resultado da pesquisa serao os fragmentos e as respetivas interpretacoes que possuam o

conjunto de palavras-chave introduzidas pelo utilizador.

4.1.2 Pesquisa Avancada

A pesquisa avancada tem como finalidade estender a pesquisa simples, para que o utilizador con-

siga procurar por fragmentos que possuam interpretacoes capazes de satisfazer os criterios selecio-

nados e parametrizados pelo utilizador. A pesquisa devera poder ser construıda a partir da selecao

de criterios preestabelecidos que reflitam as propriedades apresentadas no Capıtulo 3. Os criterios

preestabelecidos apresentarao como opcao o heteronimo, data, tipo de fonte, presenca da marca

LdoD, inclusao em edicoes de crıticas, assim como a data e heteronimo atribuıdo pelo perito no con-

texto da edicao crıtica, conteudo textual, inclusao em edicoes virtuais e taxonomias presentes nas

interpretacoes. A pesquisa devera ser composta por uma ou mais opcoes, nao havendo um limite de

opcoes que o utilizador pode adicionar, inclusive, a mesma opcao devera poder aparecer varias vezes

com diferentes parametrizacoes.

A selecao de fragmentos que satisfazem a pesquisa e determinada pelo conjunto de criterios da

pesquisa, isto e, permutacoes de criterios do mesmo conjunto de pesquisa produzirao sempre o mesmo

resultado. Tambem se devera ter um consideracao o facto de o conjunto de opcoes de pesquisa nao e

fechado, havendo uma porta aberta para a introducao de novos criterios.

O resultado sera um conjunto de fragmentos cujas interpretacoes satisfacam os criterios apresenta-

dos segundo o modo definido pelo utilizador, isto e, para cada um dos criterios, existe pelo menos uma

interpretacao que satisfaz o criterio. Por exemplo, uma pesquisa pode ser composta por duas opcoes

de heteronimo, uma indicas Bernardo Soares e outra Vicente Guedes, indicando o modo de verificacao

26

em que todos os criterios tem de se verificar nas interpretacoes de um fragmento O resultado desta

pesquisa seriam fragmentos com pelo menos uma interpretacao atribuıda a Bernardo Soares e pelo

menos uma interpretacao atribuıda a Vicente Guedes.

4.2 Recomendacoes

A concretizacao das funcionalidades da vertente livro do Arquivo LdoD descritas na Seccao 2.1

lida com a construcao de um sistema recomendacoes capaz de apurar o grau de semelhanca entre

fragmentos. O grau de semelhanca devera ser uma metrica quantificavel e comparavel, permitindo que

o sistema identifique quais os fragmentos com maior grau de semelhanca.

O utilizador tambem devera ser capaz de exprimir a relevancia que pretende dar a cada um dos

criterios que orientarao a recomendacao.

4.2.1 Navegacao por Recomendacao

A navegacao por recomendacao devera ser uma via alternativa de navegar pelo Arquivo LdoD que

complemente as formas de navegacao ja implementadas. O Arquivo LdoD ja oferece tres vias de na-

vegar pelo LdoD seguindo a ordenacao dos fragmentos num determinado contexto. Estas apresentam

os fragmentos que antecedem e sucedem o fragmento que esta a ser visualizado segundo um dos tres

contextos que se encontram definidos. A equipa do LdoD concebeu uma ordenacao dos fragmentos du-

rante a sua codificacao, criando um contexto para as fontes. As edicoes crıticas estabelecem cada uma

delas uma ordenacao para os fragmentos do LdoD, estabelecendo o contexto da apreciacao crıtica de

um perito. As edicoes virtuais tambem exprimem a ordenacao que foi dada aos fragmentos no contexto

de uma edicao virtual. Durante a visualizacao de um fragmento sao apresentadas as edicoes onde

se encontra uma interpretacao do fragmento, uma indicacao do numero do fragmento assim como os

fragmentos que se encontram antes e depois no contexto da edicao.

O sistema de recomendacao devera ser usado para identificar os fragmentos com maior grau de

semelhanca com o fragmento que esta a ser visualizado e como uma alternativa a navegacao no con-

texto de uma edicao virtual em que o utilizador colabore segundo criterios que o utilizador devera poder

parametrizar.

4.2.2 Ordenacao de Edicoes

A ordenacao de edicoes surge como outra finalidade que se pretende dar ao sistema de recomendacao.

O utilizador devera ser capaz de selecionar um fragmento, representado pela sua interpretacao vir-

tual no ambito de uma edicao virtual. A partir de um conjunto de criterios que definiu, o sistema de

recomendacao devera ser capaz de efetuar uma ordenacao descendente dos fragmentos incluıdos na

edicao segundo o grau de semelhanca em relacao ao fragmento selecionado. Assim sendo, o resultado

desta ordenacao sera um edicao virtual onde o primeiro fragmento e o fragmento selecionado pelo utili-

zador e a posicao de cada um dos outros fragmentos da edicao expressa a similaridade com o primeiro

27

fragmento, podendo-se afirmar que o fragmento numero cinco da edicao e o quarto fragmento com o

maior grau de semelhanca com o primeiro fragmento da edicao.

Ao selecionar um fragmento no contexto de uma interpretacao virtual, que apenas possui interpretacoes

atribuıdas a Bernardo Soares e indicar que a ordenacao devera ser feita por semelhanca do heteronimo,

a lista apresentada devera surgir com os fragmentos que apenas possuam interpretacoes atribuıdas

a Bernardo Soares no inıcio comecando a divergir para fragmentos com interpretacoes com outras

atribuicoes heteronomicas a medida que percorre a lista, por exemplo, os fragmentos que atribuem

uma interpretacao a Vicente Guedes e as restantes interpretacoes a Bernardo Soares, deverao surgir

depois.

4.2.3 Criacao Automatica de Seccoes

A criacao automatica de seccoes surge no seguimento da ordenacao de edicoes. Esta funcionali-

dade devera ser capaz de dividir uma edicao virtual em seccoes,em que todos os fragmentos incluıdos

numa seccao expressam o mesmo grau de semelhanca com o fragmento selecionado, segundo os

criterios introduzidos pelo utilizador. A criacao automatica de seccoes tambem devera ser capaz de

criar seccoes recursivamente, isto e, o utilizador devera poder indicar o numero de iteracoes que pre-

tende efetuar e os criterios a aplicar em cada iteracao. Mais uma vez, os fragmentos presentes numa

subseccao expressam o mesmo grau de semelhanca com o fragmento selecionado.

28

5Interface Proposta

Contents5.1 Interface proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2 Pesquisa Simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.3 Pesquisa Avancada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.4 Ordenacao de Edicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.5 Ordenacao Encaixada de Edicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

29

O Capıtulo 5 apresenta a interface acordada com a equipa do LdoD para concretizar as funcionali-

dades apresentadas no Capıtulo 4.

5.1 Interface proposta

Neste capıtulo iremos apresentar as interfaces que celebram o compromisso efetuado com a equipa

do LdoD quanto as funcionalidade que serao introduzidas na aplicacao, resultantes do trabalho desen-

volvido no ambito desta dissertacao. As interfaces resumem a vertente livro do arquivo LdoD e definem

os objetivos concretos do trabalho face as expetativas do projeto.

5.2 Pesquisa Simples

A interface proposta para a pesquisa simples espelha a natureza concreta e objetiva da tarefa que

concretiza. A Figura 5.1 apresenta a interface acordada, que resume a operacao que esta funcionali-

dade pretende facultar.

Figura 5.1: Interface da pesquisa simples.

O utilizador insere as palavras que pretende procurar, neste exemplo o utilizador procura por frag-

mentos cuja interpretacoes contenham as palavras problema e nenhum. O resultado e exibido, no qual

sao apresentadas as interpretacoes com as palavras introduzidas pelo utilizador e o fragmento que

contem a interpretacao, isto e, apresenta todos os fragmentos com pelo menos uma interpretacao que

contenha as palavras da pesquisa.

30

O utilizador devera poder navegar tanto para o fragmento como para a interpretacao e visualiza-la.

5.3 Pesquisa Avancada

A dimensao dinamica da pesquisa avancada lida com a construcao de uma pesquisa a partir de

criterios e um modo de pesquisa. As interfaces apresentadas nesta seccao pretendem exercitar este

princıpio e estabelecer um ponto de partida para orientar a sua construcao atraves da demarcacao dos

criterios de pesquisa e da concretizacao da semantica dos modos de pesquisa.

Os modos de pesquisa concretizam dois tipos de pesquisas. O primeiro modo seguira a logica de

que os fragmentos a incluir no resultado da pesquisa necessitam de respeitar todos os criterios, isto

e, tem de possuir pelo menos uma interpretacao capaz de justificar todos os criterios. Por outro lado,

o modo de inclusao disjuntivo segue uma estrategia em que se considera que um fragmento satisfaz

a pesquisa quando possuir pelo menos uma interpretacao capaz de satisfazer pelo menos um dos

criterios.

Para alem de acordar a interface a apresentar, tambem foram delineadas quais a opcoes a dis-

ponibilizar ao utilizador para construir as suas pesquisas. De seguida apresentaremos as opcoes a

disponibilizar no ambito desta dissertacao e que refletem a discussao efetuada no Capıtulo 3.

Heteronimo

A opcao de pesquisa de heteronimo permite ao utilizador pesquisar por fragmentos com interpretacoes

atribuıdas ao heteronimo selecionado.

Data

O opcao referente a data permitira ao utilizador procurar por fragmentos com interpretacoes cria-

das no ano introduzido pelo utilizador.

Inclusao nas edicoes dos peritos

A opcao de inclusao nas edicoes de peritos tem como objetivo permitir ao utilizador selecionar

fragmentos com interpretacoes incluıdas na edicao crıtica.

Fonte Autoral Manuscrita

A fonte manuscrita permite pesquisar por fragmentos com fontes manuscritas. Este pode ser

refinado, indicado a presenca da marca LdoD e o ano em que foi escrito.

Fonte Autoral Datilografada

O comportamento da pesquisa sobre fonte datilografada e um tudo analogo a pesquisa sobre

fonte manuscrita, todavia o foco desta sao fragmentos com interpretacoes de fontes datilografas.

Fonte Publicada

Esta opcao permitira a procura por fragmentos que tenham sido publicados, sendo possıvel refinar

para identificar um local de publicacao especıfico.

31

Texto

A pesquisa textual surge como opcao com um comportamento analogo a pesquisa simples, pro-

curando por fragmentos com um conjunto de palavras-chave.

Inclusao nas edicoes virtuais

A inclusao em edicoes virtuais tem como proposito extrapolar o comportamento da inclusao nas

edicoes de peritos para o ambito das edicoes virtuais do utilizador, podendo pesquisar por frag-

mentos que tenham sido incluıdos na edicao virtual selecionada.

Taxonomias

A pesquisa sobre taxonomias permite ao utilizador pesquisar por fragmentos com interpretacoes

virtuais etiquetadas com um conjunto de taxonomias.

Deste modo pela composicoes dos varios criterios resultam fragmentos cujas interpretacoes sa-

tisfazem cada um dos criterios introduzidos, de acordo com a inclusao conjuntiva ou disjuntiva, e as

interpretacoes apresentadas nos resultados da pesquisa apenas mostram as interpretacoes onde pelo

menos um dos criterios e satisfeito. Assim sendo as interpretacoes que nao justificam a presenca do

fragmento, isto nao, nao satisfazem qualquer criterio, nao sao apresentadas.

De seguida expomos exemplos de pesquisas e apresentaremos a interface que devera concretizar

a pesquisa.

Figura 5.2: Interface da pesquisa avancada com opcao de heteronimo.

Assim sendo, uma pesquisa que procure por fragmentos atribuıdos a Vicente Guedes, devera res-

ponder com todos os fragmentos que possuam pelo menos uma interpretacao atribuıda Vicente Gue-

des. A Figura 5.2 apresenta a interface que concretiza a pesquisa.

Tratando-se de uma interface dinamica onde a pesquisa e feita pela composicao de varios criterios, a

32

representacao dos varios criterios tera de acompanhar esta funcionalidade. Deste modo, uma pesquisa

que procure por fragmentos incluıdos na edicao de Teresa Sobral Cunha e fragmentos atribuıdos a

Vicente Guedes, tal como se apresenta na Figura 5.3 num modo de pesquisa em que o fragmento tem

de respeitar todos os criterios de pesquisa, teremos como resultado todos os fragmentos que possuam

pelo menos uma interpretacao de perito na edicao crıtica de Teresa Sobral Cunha e uma interpretacao

atribuıda a Vicente Guedes.

Figura 5.3: Interface da pesquisa avancada com opcao de heteronimo e inclusao editorial.

O utilizador tambem pode refinar a opcao de inclusao em edicoes crıticas definindo o heteronimo,

assim sendo, e possıvel pesquisar por fragmentos incluıdos na edicao crıtica de Teresa Sobral Cunha e

atribuıdos a Vicente Guedes no contexto desta edicao, como se encontra representado pela Figura 5.4

33

Figura 5.4: Interface da pesquisa avancada com opcao de inclusao editorial.

De notar que esta pesquisa e diferente da anterior, pois a condicao de heteronimo esta definida no

ambito da edicao de Teresa Sobral Cunha, so os fragmentos que possuam pelo menos uma interpretacao

virtual na edicao de Teresa Sobral Cunha que tambem esta atribuıda a Vicente Guedes. As duas

condicoes tem de ser satisfeitas pela mesma interpretacao, ao passo que a pesquisa anterior poderia

ser satisfeita por duas interpretacoes, uma interpretacao na edicao crıtica e outra atribuıda a Vicente

Guedes.

A logica e seguida independentemente do numero de criterios introduzidos. Uma pesquisa que pro-

cure por fragmentos com uma fonte autoral manuscrita com a marca LdoD, atribuıdo a Vicente Guedes,

introduzido na edicao de Teresa Sobral Cunha e introduzido na Edicao de Jacinto Prado Coelho onde

foi atribuıdo a Bernardo Soares e datada entre 1915 e 1925, seguindo o modo de pesquisa em todos

os fragmentos tem de respeitar todos os criterios de pesquisa.

A Figura 5.5 apresenta a interface desta pesquisa.

34

Figura 5.5: Interface da pesquisa avancada com multiplas opcoes.

O resultado desta pesquisa serao todos os fragmentos que tenham pelo menos uma interpretacao

que satisfaca cada um dos criterios, isto e, tem uma interpretacao de fonte autoral manuscrita, cuja fonte

esta marcada com a marca LdoD, uma interpretacao atribuıda a Vicente Guedes, uma interpretacao

de perito na edicao de Teresa Sobral Cunha e uma interpretacao de perito na edicao de Jacinto Prado

Coelho, atribuıda a Bernardo Soares e datada entre 1915 e 1925.

35

Figura 5.6: Interface da pesquisa avancada com multiplas opcoes disjuntas.

Em oposicao ao exemplo anterior, temos o modo selecionado para que os fragmentos apenas preci-

sem de satisfazer um dos criterios, como se apresenta na interface da Figura 5.6. Portanto o resultado

desta pesquisa serao todos os fragmentos que tenham pelo menos uma interpretacao que satisfaca

um dos criterios, ou seja, ou uma interpretacao de fonte autoral manuscrita, cuja fonte esta marcada

com a marca LdoD ou uma interpretacao atribuıda a Vicente Guedes ou uma interpretacao de perito

na edicao de Teresa Sobral Cunha ou uma interpretacao de perito na edicao de Jacinto Prado Coelho

atribuıda a Bernardo Soares.

5.4 Ordenacao de Edicoes

A ordenacao de edicoes sera limitada a edicoes virtuais dos utilizadores, considerando-se que os

fragmentos incluıdos numa edicao virtual definem o espaco de potenciais fragmentos a recomendar. A

interface conceptualizada para apresentar a ordenacao de edicoes virtuais e exposta na Figura 5.7.

36

Figura 5.7: Interface antes da ordenacao.

Esta apresenta os criterios acordados com a equipa LdoD para orientar a ordenacao e uma forma

de calibrar a relevancia de cada um deles.

A ordenacao e efetuada mostrando a semelhanca do primeiro elemento da lista. A Figura 5.8 apre-

senta uma ordenacao que foi efetuada para o fragmento numero 7.

Figura 5.8: Interface depois da ordenacao.

Temos assim que o fragmento numero 4 e o fragmento com maior grau de semelhanca face ao

fragmento 7, seguido pelo 4 ate ao menos semelhante, isto e, o fragmento numero 6.

37

Tal como se encontra apresentado na interface de ordenacao, exemplificado pela Figura 5.7, criterios

podem ser combinados e parametrizados, sendo possıvel indicar que a ordenacao deve dar uma grande

relevancia a semelhanca entre heteronimos e tema do texto, alguma relevancia a edicao, pouca re-

levancia a semelhanca entre fontes e nenhuma relevancia a semelhanca de data e taxonomia de

Antonio Quadros.

A interface a tambem apresenta os criterios de recomendacao a introduzir na aplicacao, permitindo

ao utilizador afinar a recomendacao segundo as suas preferencias. Mais uma vez, estes criterios

refletem a analise efetuada no Capıtulo 3.

Heteronimo

O criterio de recomendacao de heteronimo pretender definir a relevancia da semelhanca entre os

heteronimos encontrados nas interpretacoes de um fragmento.

Data

A data segue uma estrategia semelhante, mas agora orientada a data em vez do heteronimo, esta

tem como objetivo determinar a semelhanca entre fragmentos atraves da proximidade temporal

apresentada nas interpretacoes.

Edicao

A inclusao nas edicoes de peritos pretende encontrar o grau de semelhanca entre fragmentos

baseando-se na inclusao do fragmento nas edicoes de crıticas, assim como a atribuicao hete-

ronomica e data atribuıda pelo editor.

Fonte

A fonte expressa o grau de semelhanca entre fragmentos atraves da existencia de fontes , manus-

critas, datilografadas ou publicas, assim como compara as caracterısticas das fontes manuscritas

e datilografas quanto a presenca da marca LdoD e data em que foi escrita.

Texto

A semelhanca textual depreende-se com identificacao do tema do texto das varias interpretacoes

e conseguente avaliacao do grau de semelhanca de fragmentos com base no tema do texto.

Taxonomias

Quanto as taxonomias, serao apresentadas as varias taxonomias da edicao virtual e extrapolarao

o grau de semelhanca pela categorias da taxonomia. No exemplo apresentado pelas Figuras 5.7

e 5.8, a edicao virtual apenas possui uma taxonomia associada, a Taxonomia de Antonio Quadros.

5.5 Ordenacao Encaixada de Edicoes

A ordenacao encaixada vincula a divisao de uma edicao virtual em seccoes que traduzem o mesmo

grau de semelhanca entre os varios fragmentos que compoem a seccao, atraves da aplicacao recursiva

de criterios.

38

Assim sendo, partindo uma interface semelhante a da ordenacao de seccoes apresentado na Fi-

gura 5.7, temos a interface de configuracao de uma ordenacao encaixada de edicoes demonstrada na

Figura 5.9 que apresenta o ponto de partida para esta ordenacao e divisao.

Figura 5.9: Interface antes da ordenacao encaixada.

Neste exemplo temos uma ordenacao em que o criterio de heteronimo na primeira iteracao e a

taxonomia de Antonimo Quadros na segunda iteracao. Os criterios assinalados sem peso ou com a

iteracao marcada com o valor 0 nao serao considerados nesta ordenacao, permitindo que o utilizador

expresse claramente quais os criterios a usar.

Deste modo a edicao sera dividida em seccoes organizadas com dois nıveis, tal como apresentado

na Figura 5.10.

39

Figura 5.10: Interface depois da ordenacao encaixada.

Podemos observar a primeira divisao em duas seccoes que representam os dois heteronimos en-

contrados, Bernardo Soares e Vicente Guedes, onde encontramos os fragmentos atribuıdos a cada um

destes heteronimos claramente separados. Na segunda iteracao, fizemos uma divisao pela taxonomia

de Antonio Quadros, por tanto temos as seccoes do anteriores divididas em Fase Decadentista e Fase

Confessional, tal como exemplificado na Figura 5.10. Esta representacao permite uma facil constatacao

da seccao em que o fragmento se insere, o fragmento ”Nehum problema tem solucao”, esta identificado

como pertencendo a Fase Decadentista segundo a taxonomia de Antonimo Quadros e atribuıdo a Ber-

nardo Soares. De notar que nao existe a seccao Fase Confessional na seccao de Vicente Guedes, pois

os fragmentos desta edicao nao apresenta esta combinacao de criterios.

40

6Solucao

Contents6.1 Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.2 Navegacao por Recomendacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.3 Ordenacao de Edicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.4 Sistema de Recomendacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

41

O Capıtulo 6 ira apresentar a estrategia adotada para solucionar os problemas apresentados no

Capıtulo 4 que orientara a implementacao descrita no Capıtulo 7.

6.1 Pesquisa

6.1.1 Pesquisa Simples

A interface apresentara uma caixa de texto onde o utilizador sera convidado a inserir um conjunto

de palavras, apos pressionar o botao de pesquisa, ira efetuar um pedido ao servidor que apurara as

interpretacoes com o conjunto de palavras introduzidas. De seguida respondera com os fragmentos

que possuam pelo menos uma interpretacao com as palavras introduzidas.s A partir dos resultados

apresentados, o utilizador podera viajar para a pagina do fragmento ou para uma das interpretacoes

que contem as palavras introduzidas.

Quando o utilizador efetuar uma pesquisa por com as palavras ”Mar”e ”Saudade”, considera-se que

os fragmentos que possuam pelo menos uma interpretacao com as palavras ”Mar”e ”Saudade”satisfazem

a pesquisa. O resultado apresentado consistira na apresentacao dos fragmentos que satisfazem a pes-

quisa e das respetivas interpretacoes que contenham as palavras introduzidas.

6.1.2 Pesquisa Avancada

A pesquisa avancada pretende disponibilizar um conjunto de criterios na apresentacao que o utili-

zador pode adicionar, remover, selecionar, parametrizar e permutar, criando um mecanismo flexıvel e

articulado para construir uma pesquisa.

O utilizador pode ainda definir qual a forma de determinar se um fragmento satisfaz uma pesquisa,

dado que existem duas opcoes para este fim. Num dos modos, apenas os fragmentos que possuem

interpretacoes capazes de satisfazer todos os criterios da pesquisa e que serao apresentados como

resultado da pesquisa. O outro modo inclui fragmentos que tenham interpretacoes que satisfacam pelo

menos um dos criterios da pesquisa.

Com este objetivo, conceberemos o conceito abstrato de opcao, usado para representar uma ca-

racterıstica das interpretacoes e todos os valores que essa caraterıstica pode tomar. O utilizador pode

assim definir criterios de procura atraves da parametrizacao de opcoes. Desta forma uma pesquisa e

uma composicao de criterios definidos pelo utilizador e o modo de inclusao, a qual pretendemos sa-

tisfazer com interpretacoes que obedecam aos criterios. As caracterısticas refletirao as propriedades

discutidas no Capıtulo 3. As implementacoes de opcao terao a obrigacao de implementar a interface.

No final apresenta os fragmentos e interpretacoes que obedecem a pesquisa criada pelo utilizador.

A natureza do projeto obriga a que exista uma paridade entre a interface e o servidor no que

toca a representacao das opcoes. Do lado da apresentacao a principal preocupacao residira na

representacao grafica das opcoes e composicao das pesquisas. Por outro lado, o foco do servidor

sera a implementacao de um algoritmo agnostico e a implementacao das diversas concretizacoes de

pesquisas.

42

Os criterios de pesquisa a implementar ja se encontram descritos na Seccao 5.3 e refletem as propri-

edades apresentadas no Capıtulo 3. De notar que as interpretacoes podem nao ter qualquer atribuicao

no que toca ao heteronimo e data em que foi escrita. Assim sendo a pesquisa por heteronimo tambem

apresenta a hipotese de pesquisa por fragmentos com interpretacoes sem atribuicao de heteronimo e

no campo da data, teremos a hipotese de pesquisa por fragmentos com interpretacoes nao datadas.

O resultado apresentado sera sempre o fragmento e as respetivas interpretacoes que satisfazem os

criterios introduzidos pelo utilizador.

6.2 Navegacao por Recomendacao

Da concretizacao das funcionalidades da vertente livro do Arquivo LdoD descritas na Seccao 2.1

depreende-se a construcao de um sistema auxiliar capaz de identificar a semelhanca entre fragmentos,

permitindo a abertura de uma nova via de navegacao pelo LdoD, complementando as formas que ja

se encontram implementadas. O Arquivo LdoD oferece tres vias de navegar pelo LdoD, seguindo a

ordenacao dos fragmentos num determinado contexto. Estas apresentam o fragmento que antecede e

sucede num determinado contexto e o contexto encontra-se definido de tres formas. A equipa do LdoD

concebeu uma ordenacao dos fragmentos durante a sua codificacao.

As edicoes crıticas estabelecem cada uma delas uma ordenacao para os fragmentos do LdoD.

As edicoes virtuais tambem exprimem a ordenacao que foi dada aos fragmentos no contexto de uma

edicao virtual. Durante a visualizacao de um fragmento sao apresentados as edicoes, tanto virtual

como crıtica, onde se encontra uma interpretacao do fragmento. Para cada uma das edicoes e indicado

o numero do fragmento no contexto da edicao e os fragmentos que sucedem e antecedem no contexto

da edicao.

A introducao de recomendacoes surge como uma alternativa a navegacao estabelecida pela ordenacao

no contexto de uma edicao virtual, pretendendo recomendar um dos fragmentos mais semelhantes

com o que esta a ser visualizado, baseando-se nas preferencias do utilizador. Assim, no contexto das

edicoes virtuais do utilizador, teremos duas formas de navegar pelo LdoD. Atraves da ordenacao que o

utilizador deu ou atraves da semelhanca entre fragmentos. Ao navegar para fragmentos recomendados,

o fragmento que antecede e sucede tera significados diferentes. O fragmento que sucede e o fragmento

que maior nıvel de semelhanca em relacao ao que esta a ser visualizado. Por outro lado, o fragmento

que antecede e o fragmento que o utilizador visualizou anteriormente e a partir do qual navegou para

o fragmento mais semelhante, ou seja, o que esta a visualizar. De notar que o historico de fragmentes

que antecedem e mantido, permitindo ao utilizador navegar por uma edicao que esta a ser construıda

atraves da navegacao para fragmentos, em que nenhum dos fragmentos que ja foi visualizado pode

surgir como recomendacao, por ja ter sido recomendado. Desta forma evita-se que os fragmentos re-

comendados sejam selecionados de um pequeno conjunto de fragmentos muito semelhantes. Tambem

e possıvel visitar todos os fragmentos que ja foram visitados, visitando sucessivamente cada um dos

antecedentes.

A construcao da edicao e iniciada a partir do momento que o utilizador navega para o fragmento

43

com maior nıvel de semelhanca. A navegacao nesta edicao recomendada, na qual se mantem a lista de

fragmentos visitados anteriormente pela navegacao por recomendacao, mantem-se ate que o utilizador

navegue para outro fragmento que nao seja sugerido como o mais semelhante no contexto da edicao

virtual. Quando tal acontece, a ordenacao da edicao que estava a efetuar perde-se.

6.3 Ordenacao de Edicoes

A ordenacao de fragmentos sera efetuada a partir de um ecra onde serao apresentados os frag-

mentos que constituem uma edicao virtual, assim como os sliders para cada uma das propriedades e

as varias taxonomias criadas sobre a edicao. O utilizador configurara os pesos que pretende dar as

propriedades, apos selecionar um fragmento, a edicao e reordenada tendo o fragmento selecionado

como o primeiro da edicao e o resto dos fragmentos surgem ordenados pelo grau de semelhanca com

o fragmento selecionado. Sempre que o utilizador interagir com os sliders e definir novos pesos para

as propriedades, a edicao sera reordenada ou selecionar um novo fragmento para o inıcio da edicao

virtual, a interface envia os pesos de cada uma das propriedades e o fragmento selecionado. O servi-

dor comeca por guardar o peso que o utilizador deu as propriedades. De seguida constroi o vetor de

preferencias do utilizador, tomando o vetor de propriedades do fragmento selecionado e aplicando os

pesos do utilizador, multiplicando o peso da propriedade definido pelo utilizador com o valor presente

no vetor de propriedades do fragmento selecionado. De seguida extrai o vetor de propriedades de cada

um dos fragmentos da edicao virtual. A semelhanca entre o vetor de preferencias do utilizador e vetor

de propriedades dos fragmentos e assim calculada, produzindo uma lista em que os fragmentos estao

ordenados pelo grau de semelhanca com as preferencias do utilizador, por ordem descendente. De

seguida envia a nova ordenacao para a apresentacao e esta refresca a edicao apresentada com a nova

ordenacao dos fragmentos.

Apos efetuar a reordenacao de um edicao, surgem duas opcoes adicionais, permitindo ao utilizador

guardar a edicao atual com a configuracao atual, isto e, tornar as alteracoes permanentes. Tambem

pode criar uma nova edicao virtual com a configuracao apresentada. Ao guardar a nova configuracao, a

interface envia a lista de fragmentos que esta a apresentar. O servidor trata de alterar a numeracao dos

fragmentos dentro da edicao, refletindo a nova ordenacao. Apos ordenar, envia a lista de fragmentos de

volta para a apresentacao. A apresentacao refresca a seccao da vista que apresenta os fragmentos. A

ordem dos fragmentos ira manter-se, mas o seu numero sera atualizado. Quando o utilizador pretende

criar uma nova edicao com a configuracao apresentada, o utilizador introduz o nome, sigla da nova

edicao e polıtica de acesso. A apresentacao envia a lista de fragmentos ordenada tal como apresen-

tado, juntamente com o nome e sigla da edicao a criar. O servidor cria a edicao com o nome, sigla

e polıtica de acesso. Tambem cria novas interpretacoes virtuais dos fragmentos e insere-os na nova

edicao pela ordem desejada. O servidor responde com a pagina de visualizacao de edicoes virtuais

para a edicao criada. A interacao apresentada sera concretizada atraves do uso de chamadas Ajax e a

definicao de controladores capazes de processar cada um desses pedidos.

44

6.3.1 Ordenacao Encaixada de Edicoes

A ordenacao encaixada e uma forma alternativa de ordenar onde tambem se pretende seccionar

uma edicao. O utilizador configura o peso e os criterios que pretende usar. Sempre que o utilizador al-

terar o peso, os criterios ou selecionar outro fragmento, a apresentacao envia o fragmento selecionado,

pesos e iteracao das propriedades para o servidor. O servidor trata de guardar os pesos do utilizador

para a edicao e extraı o vetor de preferencias do utilizador. De seguida aplica a primeira iteracao, sele-

cionado as propriedades associadas ao primeiro criterio e agrupa os fragmentos com o mesmo grau de

semelhanca, criando clusters. A partir dos clusters criados, aplica a segunda iteracao, com as proprie-

dades do segundo criterio, dividindo cada um dos clusters em mais clusters. O processo e repetido ate

que todos os criterios tenham sido processadas. Deste modo, todos os fragmentos dentro de um cluster

tem o mesmo grau de semelhanca com o fragmento selecionado, para os pesos dos criterios. Os clus-

ters sao ordenados por ordem descendente pelo grau de semelhanca com o fragmento selecionado.

No final o servidor responde com a lista de fragmentos, devidamente agrupada. Tal como na funci-

onalidade anterior, o utilizador pode guardar a configuracao atual dos fragmentos ou criar uma nova

edicao com a configuracao apresentada. Assim sendo, quando esta a processar a nova configuracao

do lado do servidor, a edicao virtual e dividida em seccoes com o intuito de refletir os clusters obtidos.

O uso de chamadas Ajax ira implementar o comportamento apresentado. Desta forma, o controlador

ira implementar tres controladores, capazes de ordenar, guardar e criar uma nova edicao com seccoes.

A apresentacao tambem sera capaz de identificar o modo de trabalho em que esta a executar, isto e,

ordenacao normal ou encaixada, e construir as chamadas para o controlador certo.

6.4 Sistema de Recomendacao

No seguimento da reflexao efetuada no final da Seccao 2.3, na qual indicamos o sistema baseado

em conteudo seguindo uma abordagem baseada em memoria como a melhor estrategia a aplicar no Ar-

quivo LdoD, devido a dimensao expectavel da aplicacao no que toca ao numero de utilizadores e itens.

Esta ideia foi reforcada pela exposicao feita no Capıtulo 3, onde indicamos possıveis caracterısticas

do Arquivo LdoD que podemos usar como propriedades para sustentar recomendacoes baseadas em

conteudos. Assim sendo, podemos formalizar o sistema de recomendacao do arquivo LdoD como um

sistema de recomendacao baseado em conteudos, seguindo uma abordagem baseada em memoria,

suportado pelas propriedades das fontes e interpretacoes, assente em indicadores explıcitos para indi-

car as preferencias do utilizador.

A semelhanca entre fragmentos sera determinada por intermedio da modelacao de fragmentos

atraves de VSM tal como apresentado na Seccao 2.2, isto, modelando os fragmentos em vetores de

propriedades e determinando o seu grau de semelhanca com o vetor de preferencias do utilizador,

recorrendo a coisine similarity tal como aprestada na Seccao 2.2.

45

6.4.1 Vetores de Preferencias do Utilizador

A recolha de preferencias do utilizador sera feita atraves de indicadores explıcitos. O utilizador

tomara um fragmento como ponto de partida e depois configurara a relevancia que pretende dar a cada

uma das propriedades apresentadas em 6.4.2, criando um vetor que representa as suas preferencias e

a partir do qual serao produzidas as recomendacoes. A interface apresentara um forma de controlar o

grau de relevancia que o utilizador pretende dar a cada uma das propriedades. Sempre que o utilizador

alterar a relevancia que pretende dar uma das propriedades, esta sera guardada de forma permanente

e usada A relacao traduz assim o contexto de cada conjunto de pesos, ou seja, existira um conjunto de

pesos para combinacao de utilizador e edicao virtual.

6.4.2 Vetores de Propriedades do Fragmento

O esquema apresentado dependera agora da recolha do vetor de preferencias do utilizador, ca-

paz de expressar os interesses do utilizador e a modelacao dos fragmentos em vetores segundo as

suas propriedades. As propriedades a usar no sistema advem das caracterısticas apresentadas no

Capıtulo 3. Estas caracterısticas introduzem um contexto para o vetor de propriedades e serao ex-

pressadas com base nesse contexto. Atraves da combinacao dos vetores de varios contextos, iremos

expandir a comparacao para que seja possıvel expressar comparacoes sobre varias caracterısticas. De

seguida apresentaremos as caracterısticas que consideramos. Cada uma destas caracterısticas sera

representada por um vetor de propriedades. Convenciona-se assim que o vetor de propriedades de

heteronimo de um fragmento pretende representar apenas as propriedades referentes ao heteronimo

do fragmento.

Heteronimo

A informacao referente ao heteronimo estara refletida sobre um vetor onde cada posicao re-

presenta um heteronimo presente no arquivo. O heteronimo seguira uma abordagem binaria

baseada na existencia de pelo menos uma interpretacao atribuıda ao heteronimo, esta foca-se

apenas na existencia de interpretacoes atribuıdas ao heteronimo, sem dando qualquer tipo de

enfase ao numero de interpretacoes atribuıdas ao heteronimo. Nesta formulacao, o valor a intro-

duzir nao e afetado pelo numero de interpretacoes que estao atribuıdas a um dado heteronimo,

traduzindo-se sempre no mesmo valor. Deste modo, a posicao de um dado heteronimo surgira a

1 quando existe pelo menos uma interpretacao do fragmento atribuıda aquele heteronimo. Caso

nao exista pelo menos uma interpretacao atribuıda ao heteronimo, a posicao que o pretende re-

presentar no vetor aparecera a 0. Uma alternativa a esta estrategia seria o uso da frequencia do

heteronimo, em que o valor a colocar em cada posicao passaria a ser o quociente entre o numero

de interpretacoes atribuıdas ao heteronimo sobre o numero interpretacoes do fragmento. Nesta

abordagem o numero de interpretacoes atribuıdas a um heteronimo reforca a sua presenca no

fragmento, refletida pelo valor introduzido na posicao do vetor que o representa.

Neste momento, o arquivo tem digital comporta apenas tres heteronimos, Bernardo Soares, Vi-

cente Guedes e nao atribuıdo, assim sendo, a primeira posicao representa Bernardo Soares, a

46

segunda posicao a Vicente Guedes e a terceira posicao representa interpretacoes nao atribuıdas.

Um fragmento que so tenha interpretacoes atribuıdas a Bernardo Soares sera representado pelo

vetor v1 da Figura 6.1, pois so existem interpretacoes atribuıdas a Bernardo Soares.

Por outro lado, um fragmento com interpretacoes sem atribuicao e uma interpretacao atribuıda

a Vicente Guedes surge representado pelo vetor v2 da Figura 6.1, por existem interpretacoes

atribuıdas a Vicente Guedes e interpretacoes sem atribuicao.

Bernardo Soares Vicente Guedes Sem Atribuicaov1 1 0 0v2 0 1 1

Tabela 6.1: Vetores de propriedades de heteronimo.

Data

A data e representada num vetor de preferencias como tendo cada posicao associada a um ano

em que o fragmento pode ter sido escrito. Deste modo, para criar o vetor de propriedades de um

fragmento, as interpretacoes do fragmento sao analisadas para extrair o ano em que foi escrito

segundo a interpretacao. Cada posicao do vetor representa um ano e cada posicao pode ter o

valor de um, caso uma das suas interpretacoes esteja datada com uma data daquele ano, ou

zero, quando nao existem interpretacoes com a data do ano em questao.

s(v, u) = s({1, 0, 1}, {0, 1, 0}) =1 ∗ 0 + 0 ∗ 0 + 1 ∗ 0√

12 + 02 + 12 ∗√

02 + 12 + 02= 0 (6.1)

Coisine similary entre vetores ortogonais.

Com o esquema atual, apenas poderıamos exprimir um certo grau de semelhanca entre fragmen-

tos que tenham pelo menos uma data em comum, sendo impossıvel exprimir um grau concreto

de semelhanca para fragmentos que tenham sido escritos em anos consecutivos, pois os seus

vetores de propriedades sao ortogonais e o grau de semelhanca entre vetores ortogonais e 0. A

Figura 6.1 apresenta esta impossibilidade.

Introduz-se assim a necessidade de preencher as posicoes adjacentes a posicao que representa

a data de uma das interpretacoes, introduzindo um declınio que permita estabelecer um relaci-

onamento entre fragmentos com datas proximas. A Figura 6.2 representa dois vetores de pro-

priedades para a data, onde o fragmento F1 e composto por interpretacoes datadas com 1925

e 1927, F2 tem interpretacoes datadas com 1929 e F3 com interpretacoes datadas com 1926 e

1929.

1925 1926 1927 1928 1929F1 1 0 1 0 0F2 0 0 0 0 1F3 0 1 0 0 1

Tabela 6.2: Vetores de propriedades de data sem declınio.

47

Os fragmentos com as caracterısticas apresentadas so consegue exprimir um grau de semelhanca

para F2 e F3, no entanto, F3 tem uma interpretacao datada com 1926 e F1 interpretacoes datadas

com 1925 e 1927, ou seja, datas muito proximas que o modelo atual impossibilita a expressao

de um grau de semelhanca diferente de 0. Ao introduzir o conceito de declınio, temos que as

posicoes adjacentes a uma data de uma interpretacao possuem um valor inferior a um que ira

decrescer a medida que se afastam da posicao que representa a data. A ideia e que as posicoes

que representem datas sejam picos de incidencia e que as posicoes adjacentes manifestem parte

da incidencia que vai atenuando a medida que se afasta do pico. Na Figura 6.3 podemos observar

os vetores de propriedades de data para os fragmentos F1, F2 e F3 com um declınio de 0.1.

1925 1926 1927 1928 1929F1 1 0.9 1 0.9 0.8F2 0.6 0.7 0.8 0.9 1F3 0.9 1 0.9 0.9 1

Tabela 6.3: Vetores de propriedades de data com declınio.

A introducao do declınio permite assim expressar relacoes entre todos os vetores.

Inclusao nas edicoes dos peritos

A representacao da apreciacao dos peritos e inclusao nas edicoes crıticas e feita atraves da

composicao das seccoes que representam cada uma das edicoes crıticas presente no Arquivo

LdoD. A seccao que representa uma interpretacao referente a uma edicao crıtica de um fragmento

e construıda tendo a primeira posicao como indicacao de que existe uma interpretacao de perito

para uma dada edicao crıtica. De seguida temos um conjunto de posicoes para representar

o heteronimo, gerado tal como descrito na propriedade heteronimo. Apos obter o subvetor do

heteronimo, temos o subvetor referente a data para a interpretacao, obtido de uma forma analoga

a propriedade data. Tendo em conta a configuracao atual, o Arquivo LdoD tem quatro edicoes

crıticas, assim sendo, o vetor de propriedades da inclusao de peritos sera composto por seccoes.

O vetor apresentado na Figura 6.1 representa as propriedades de inclusao de um fragmento que

possui uma interpretacao na edicao crıtica de Jacinto Prado Coelho, uma interpretacao na edicao

crıtica de Teresa Sobral Cunha e uma interpretacao na edicao crıtica de Richard Zenith.

1 .. .. .. .. .. 1 .. .. .. .. .. 1 .. .. .. .. .. 0 .. .. .. .. ..︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸Heteronimo Data Heteronimo Data Heteronimo Data Heteronimo Data︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸

Coelho Cunha Zenith Pizarro

Figura 6.1: Vetor de propriedades da inclusao nas edicoes de peritos.

Fontes

O vetor que pretende representar as propriedades referentes as fontes divide-se em tres seccoes

que pretendem representar as propriedades dos tres tipos de fontes.

48

A primeira seccao representa as propriedades referentes a existencia de fontes autorais manus-

critas. A primeira posicao representa a existencia de pelo menos uma fonte autoral manuscrita

e segue uma logica binaria, isto e, assume o valor 1 quando existe pelo menos uma fonte au-

toral manuscrita ou 0 quando nao existe. A segunda desta seccao representam a existencia da

marca LdoD. Ambas seguem uma abordagem binaria. A segunda posicao assume o valor um

quando existe pelo menos uma interpretacao de uma fonte autoral com a marca LdoD ou zero

quando nao existe nenhuma interpretacao de fonte autoral com a marca LdoD. De seguida temos

a informacao referente a data que segue um processamento analogo ao descrito na propriedade

data e produz um vetor semelhante para a interpretacao autoral manuscrita.

A segunda seccao representa as propriedades da interpretacao de fonte autoral datilografada e

segue uma estrutura em tudo semelhante a da interpretacao de fonte autoral manuscrita.

A terceira seccao representa a existencia de fontes autorais publicadas e contem apenas uma

posicao. Esta pretende tomar o valor de um quando o fragmento possui pelo menos uma interpretacao

de uma fonte autoral publicada ou zero quando nao existe nenhuma.

O vetor de propriedades que representam as fontes de autorais e composto por estas tres seccoes

sempre pela mesma ordem, primeiro a seccao referente as interpretacoes de fontes autorais

manuscritas, seguido da seccao referente as interpretacoes de fontes autorais datilografadas e

por ultimo as interpretacoes de fontes autorais publicadas. Assim sendo, um fragmento com duas

interpretacoes de fontes autorais manuscritas com a marca LdoD, uma interpretacao de fonte

autoral datilografada sem a marca LdoD e sem interpretacoes de fontes publicadas e representado

pelo Vetor 6.2.

1 1 1 0 0 .. .. .. 1 0 1 0 0 .. .. .. 0 0 0 0 .. .. ..︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸Heteronimo Data Heteronimo Data Heteronimo Data︸ ︷︷ ︸ ︸ ︷︷ ︸ ︸ ︷︷ ︸

Fonte Manuscrita Fonte Datilografada Fonte Publicada

Figura 6.2: Vetor de propriedades das fontes.

Texto

O vetor de propriedades referente ao texto e construido com recurso a identificacao das palavras

mais frequentes de cada fragmento atraves do calculo do TF-IDF dos termos encontrados nas

varias interpretacoes do fragmento. Assim sendo, extraem-se os cem termos com o valor mais

alto de TF-IDF para cada fragmento. Para este calculo, considera-se que o fragmento e um

documento e a frequencia dos termos e extraıda a partir dos textos suas interpretacoes.

F1 F2Agua 2 3Aguia 5 0

Apeadeiro 0 4

Tabela 6.4: Frequencia dos termos.

49

Desta forma obtem-se um vetor que contem os termos mais significativos de cada um dos frag-

mentos.

Os vetores de propriedades apresentados ate este instante representam propriedades cuja di-

mensao esta definida nas propriedades da aplicacao. O numero de heteronimos e o numero de

edicoes crıticas esta explicitamente declarada e e facil de inferir, sendo possıvel averiguar a di-

mensao do vetor antes de processar os fragmentos. Esta caracterıstica nao e partilhada pelas

propriedades textuais, a dimensao do vetor do propriedades textuais e definido apos a extracao

dos termos mais frequentes de cada um dos fragmentos a comprar. A dimensao do vetor e dado

pela uniao do conjunto de termos mais frequentes de cada um dos fragmentos, podendo oscilar.

Para cada fragmentos sao extraıdos os cem termos mais frequentes, portanto o vetor podera ter

entre cem posicoes, quando os termos mais frequentes sao os mesmos, a duzentos posicoes,

quando a intercecao dos conjuntos de termos e vazia, isto e, nao tem nenhum termo em comum.

O numero de termos a extrair de cada fragmento limitou-se nos cem, pois as recomendacoes

tem uma natureza interativa em que se pretende recalcular as recomendacoes sempre que o uti-

lizador modificar os criterios de recomendacao. Assim sendo, o vetor de propriedades textuais

do fragmento e construıdo a partir do vetor de termos e cada posicao tem o TF-IDF do termo

ou 0 quando o termo nao se encontra nas varias interpretacoes do fragmento. Esta propriedade

tambem poderia seguir uma logica binaria em que colocarıamos 1 quando o termo esta presente

no fragmento.

TF − IDF (Agua, F1) = TF (Agua, F1) · IDF (Agua) = 2 · log(2

2) = 0

TF − IDF (Aguia, F1) = TF (Aguia, F1) · IDF (Aguia) = 5 · log(2

1) = 1.5051499783

TF − IDF (Apeadeiro, F1) = TF (Apeadeiro, F1) · IDF (Apeadeiro) = 0 · log(2

1) = 0

TF − IDF (Agua, F2) = TF (Agua, F2) · IDF (Agua) = 3 · log(2

2) = 0

TF − IDF (Aguia, F2) = TF (Aguia, F2) · IDF (Aguia) = 0 · log(1

2) = 0

TF − IDF (Apeadeiro, F2) = TF (Apeadeiro, F2) · IDF (Apeadeiro) = 2 · log(1

2) = 1.2041199827

(6.2)

Calculo do TF-IDF.

Com base na Figura 6.4 e nos calculos efetuados em 6.2, temos que o vetor de propriedades

textuais de F1 e F2 apresentados em 6.5.

O calculo TF-IDF e efetuado atraves do produto entre TF e o IDF, tal como apresentado na

Formula 2.2, deste modo, o calculo do TF-IDF(Aguia,F1) e efetuado pelo produto de TF(Aguia)

com IDF(Aguia). O TF(Aguia,F1) e a contagem do numero de vezes que o termo Aguia surge

em F1, isto e, 5. O IDF(Aguia) corresponde ao logaritmo do inverso da frequencia. O inverso

da frequencia e calculado pelo quociente entre d numero de documentos, 2, e o numero de

50

documentos com o termo Aguia, 1, portanto temos log( 21 ).

Agua Aguia ApeadeiroF1 0 1.5051499783 0F2 0 0 1.2041199827

Tabela 6.5: Vetores de propriedades textuais de F1 e F2.

Taxonomias

Este vetor pretende representar as varias categorias de uma taxonomia que podemos encontrar

numa interpretacao virtual. Deste modo, cada posicao do vetor representa uma categoria de uma

taxonomia. Aqui enveredamos por duas abordagens no que toca ao valor que iremos colocar

em cada posicao do vetor de propriedades de uma taxonomia. Uma abordagem booleana em

que colocamos o valor 1 quando a interpretacao se encontra marcada com a categoria ou 0

quando nao possui a categoria. O modelo de domınio do Arquivo LdoD permite atribuir um peso a

categoria que marca uma interpretacao, deste modo, podemos seguir uma abordagem em que o

valor que encontramos numa posicao do vetor representa o peso que esta categoria tem naquela

interpretacao.

A permutacao de propriedades tambem sera uma preocupacao, isto e, o numero de propriedades a

usar para uma recomendacao e dinamico. Assim sendo o sistema de recomendacoes recebera sempre

uma lista de propriedades, que irao orientar a recomendacao. O vetor de propriedades do fragmento

sera assim construıdo a partir da concatenacao dos varios vetores que cada uma das propriedades irao

produzir.

51

52

7Integracao no LodD

Contents7.1 Modulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.2 Indexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.3 Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567.4 Sistema de Recomendacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617.5 Alteracoes ao Domınio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.6 Navegacao por Recomendacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687.7 Ordenacao de Edicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687.8 Ordenacao Encaixada de Edicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

53

Este capıtulo relata a implementacao e integracao das pesquisas e recomendacoes no Arquivo LdoD.

7.1 Modulos

O Arquivo LdoD e composto por varias camadas e uma vista com nıvel de abstracao alto revela

uma camada de apresentacao, uma camada aplicacional e uma camada de persistencia de dados. A

camada de apresentacao responsavel por gerir as varias vistas da aplicacao e recolher as acoes do utili-

zador. As acoes sao depois tratadas pelo nucleo aplicacional e sempre que necessarios materializadas

sobre uma base de dados MySQL da camada de persistencia de dados. Os ficheiros de configuracao

da aplicacao, assim como os facsimile dos fragmentos encontram-se no sistema de ficheiros.

A extensao da aplicacao para o tratamento de conteudo textual implicou a introducao de um modulo

capaz de processar, indexar e pesquisar texto. O modulo e suportado pela Lucene [29] e apresentado

pela Figura 7.1

Figura 7.1: Diagrama de camadas do Arquivo do Livro do Desassossego.

O Lucene [29] e uma biblioteca cuja finalidade e proporcionar mecanismos para indexar e pesquisar

documentos. A sua integracao no Arquivo LdoD tem como objetivo a indexacao e pesquisa do conteudo

textual das interpretacoes. O Lucene disponibiliza varios parametros de configuracao e uma interface

para construir queries.

Ao aumentar o nıvel de granularidade comecamos a observar os modulos no seu alinhamento com

a arquitetura Model–View–Controller (MVC) da Spring Framework, tal como se encontra demonstrado

pelo Diagrama 7.2. O modelo encontra-se aqui representado pelo modulo Domain emulando o domınio

da aplicacao concretizado atraves da Fenix Framework. As vistas sao aqui apresentados por dois nıveis,

mapeando os dois nıveis de funcionamento da apresentacao, Server-side Presentation e Cliente-side

Presentation. No lado do cliente corre sobre o browser e e responsavel pela manipulacao da interface

expondo as funcionalidades do aplicacao assim como captura as acoes do utilizador. A apresentacao

do lado do servidor depreende-se com a construcao das vistas a partir de templates devidamente

parametrizados. Os controladores capazes de processar as acoes do utilizador, atualizado o estado do

domınio e produzindo vistas.

A introducao das funcionalidades de pesquisa e recomendacao implicou o desenvolvimento de

modulos para as acomodar. A semantica do Arquivo LdoD estabeleceu a divisao do modulo de con-

troladores em varios controladores que estivessem encarregues de tratar de um conjuntos de casos

de uso dentro da mesma semantica, ditando assim a criacao de dois controladores. O controlador en-

54

Figura 7.2: Diagrama de camadas detalhado do Arquivo do Livro do Desassossego.

carregado por tratar todos os pedidos no ambito das pesquisas e assim o SearchController. Por outro

lado o controlador responsavel por tratar todos as acoes referentes as recomendacoes encontram-se

materializado sobre o RecommendationController. Os controladores estabelecem assim um ponto de

entrada para a interacao referentes a estas funcionalidades.

Tambem neste diagrama podemos observar a interacao com o Lucene. Esta foi atingida atraves

da construcao de um modulo que encapsula toda a configuracao, pedidos de indexacao e construcao

de queries, disponibilizando uma interface para efetuar pesquisa textual e extracao dos termos mais

frequentes, ao qual demos o nome de Indexer.

7.2 Indexer

O Indexer comeca por configurar o Lucene, ao nıvel do diretorio que este usara para guardar os

indexes e qual o Analyzer a usar para a sua construcao. O Analyzer permite parametrizar um conjunto

de stop words, ou seja, palavras que nao sao indexadas. A classe IgnoreDiacriticsAnalyzer surge

com o objetivo de demarcar estas palavras, recolhendo o conjunto de stop words que o Lucene ja

disponibliza na classe PortugueseAnalyzer, ignorando assim palavras da lıngua portuguesa que sao

muito frequentes.

Seguindo o esquema do Lucene, foi definido que cada documento sobre o seu controlo tem dois

atributos, o identificador do documento e a o conteudo textual. O identificador do documento e o iden-

tificador da interpretacao, isto e, o ExternalId do FragInter. Assim sendo, a indexacao de novos do-

cumentos e atingido atraves da criacao de um novo documento com os atributos id e text. O id e o

ExternalId da interpretacao e o text e o conteudo textual da interpretacao. Sempre que um fragmento

55

que se encontra codificado sobre o formato TEI e carregado para o Arquivo LdoD e materializado com

sucesso no domınio da FenixFramework, este e tambem adicionado ao Lucene.

A pesquisa por interpretacoes com um conjunto de palavras e efetuado pelo Indexer criando uma

query. Como se pretende procurar por interpretacoes com todas as palavras chaves, construımos as

pesquisas atraves do uso predicado AND. Assim sendo, a procura por interpretacoes com as palavras

Agua, Navios e Sol e feita atraves da construcao da query ”Agua AND Navios AND Sol”. O resultado

e o conjunto de ExternalId das interpretacoes que contem estas tres palavras. Para alem da pesquisa,

tambem disponibiliza um metodo semelhante para verificar se uma interpretacao contem um conjunto

de palavras-chave. A query e construıda adicionando o ExternalId a query com a indicacao do atributo

que esta a limitar, neste caso, o id. Portanto, a query ”id:90194314878 AND alma AND oculta AND

tambores” e contruıda para verificar se a interpretacao do fragmento ”Minha alma e uma orquestra

oculta;” na edicao crıtica de Teresa Sobral Cunha contem as palavras alma, oculta e tambores, sendo

que 90194314878 e o ExternalId da interpretacao.

O Indexer tambem oferece uma interface para a extracao da frequencia de termos, usado no calculo

de TF-IDF, usado nas recomendacoes. O Lucene oferece metodos para extrair os termos de um docu-

mento, assim como a frequencia do termo no documento e a frequencia de documentos com o termo.

Assim sendo, a identificacao e calculo de TF-IDF usa as frequencias absolutas, seguindo a formula

apresentada em 2.2. Dado que a recomendacao e orientada as semelhancas entre os fragmentos,

considera-se que os termos de um fragmento e o conjunto de termos de todas as interpretacoes do

fragmento. Assim sendo a frequencia de um termo num fragmento e o numero de vezes que o termo

aparece em todas as interpretacoes do fragmento. A frequencia dos documentos com o termo e o

numero de interpretacoes com o termo. O numero de documentos e o numero de interpretacoes pre-

sentes no Lucene.

A remocao de interpretacoes tambem e gerida pelo Indexer. Sempre que e detetado que o Externa-

lId de uma interpretacao que se encontra no Lucene, mas que ja nao corresponde a uma interpretacao

do domınio gerido pela FenixFramework, esta interpretacao e removida do Lucene.

7.3 Pesquisa

7.3.1 Pesquisa Simples

As palavras introduzidas pelo utilizador na pesquisa simples sao comunicadas ao servidor de Ajax

da biblioteca jQuery. Este pedido e tratado pelo SearchController definido no ambito da pesquisas

simples.

O controlador processa o conjunto de palavras para obter uma lista de termos. De seguida incumbe

o Indexer de encontrar as interpretacoes com a lista de palavras introduzidas. O Indexer constroi a

query e obtem uma lista de ExternalId, que passa ao controlador. O controlador trata de recuperar as

interpretacoes do domınio da FenixFramework a partir da lista de ExternalId e coloca a interpretacao

num mapa onde a chave e o fragmento e o valor a lista de interpretacoes do fragmento usado como

chave. Desta forma temos as interpretacoes agrupadas por fragmento. De seguida o controlador

56

retorna uma vista JSP que e instanciada com os valores do mapa, produzindo uma tabela de resultados

em HTML que e enviada para a apresentacao.

A apresentacao recebe a tabela e adiciona-a a pagina, apresentando uma tabela com interpretacoes

agrupadas por fragmento. Quando e impossıvel recuperar a interpretacao do domınio da FenixFra-

mework, o ExternalId e inserido numa lista. Antes de retornar a vista, o controlador lanca uma tarefa

assıncrona com a lista de ExternalId em falta, que invoca o Indexer e trata de remover todos os docu-

mentos do Lucene com ExternalId.

7.3.2 Pesquisa Avancada

A pesquisa apresenta uma correspondencia entre criterios a apresentar na interface e a respetiva

construcao destes mesmos no servidor para o processamento de fragmentos.

7.3.2.A Interface

A flexibilidade que se pretende dar a pesquisa avancada, exige uma interface que permita ao uti-

lizador adicionar, parametrizar e remover opcoes. Ao nıvel da interface, adotou-se uma estrategia

baseada no Model-View-Presenter (MVP). O objetivo desta abordagem e criar uma separacao entre a

apresentacao e o modelo de domınio, mediado por uma entidade que gere os mantem a consistencia

entre apresentacao e domınio.

Os objetos do domınio que representam opcoes como elementos da interface e foram codificados

em JavaScript. Estes emulam as opcoes descritas na Seccao 5.3. Para alem de conterem os atribu-

tos necessarios para planificarem as varias opcoes de pesquisa, tambem apresentam uma interface

transversal para a manipulacao dos objetos por parte do Presenter, sendo assim uma preocupacao

fundamental no desenvolvimento de futuras representacoes de opcoes. O objeto de domınio e capaz

de produzir uma representacao grafica em HyperText Markup Language (HTML) do seu estado atual

e produzir um JavaScript Object Notation (JSON) que o descreva, no que toca ao tipo e atributos da

opcao parametrizados pelo utilizador. O Presenter fica assim encarregue de manter a coerencia entre

os dados apresentados na interface e o estado dos objetos do domınio. A introducao da biblioteca

Riot [30] surge aqui como um meio de lancar eventos. Estes eventos sao lancados pelo domınio indi-

cando que o seu estado mudou e sao capturados pelo Presenter, que prontamente trata de atualizar

a interface, espelhando a alteracao efetuada. Sempre que o utilizador parametrizar uma opcao, esta e

comunicada ao Presenter que trata de encontrar o objeto do domınio correspondente e alterar o seu

estado para refletir as alteracoes efetuadas pelo utilizador.

O ciclo de interacao da pesquisa avancada e assim materializado pelo diagrama de sequencia da

Figura 7.3.

57

Figura 7.3: Diagrama de sequencia da pesquisa avancada.

O Presenter e ainda responsavel por serializar os criterios para JSON, enviar para o servidor quando

o utilizador pressionar o botao de pesquisa, e adicionar a resposta a pagina, ou substituir a resposta

anterior.

A nıvel da interface, podemos ver a sua concretizacao na Figura 7.4, onde estamos a construir uma

pesquisa com varios criterios.

Figura 7.4: Interface de pesquisas avancadas.

58

7.3.2.B Servidor

A implementacao das opcoes descritas na Seccao 6.1.2 depreendem-se com a verificacao dos

fragmentos que possuem interpretacoes capazes de satisfazer os criterios presentes na lista. Com

esse objetivo, adotamos um visitor capaz de identificar em tempo de execucao o tipo de interpretacao

que esta a ser processado e verificar se a interpretacao satisfaz algum dos criterios da pesquisa. Sendo

assim, cada interpretacao de um fragmento aceita o objeto abstrato de opcao que por sua vez processa

a interpretacao, determinando se a interpretacao satisfaz o criterio.

Quando um fragmento tem interpretacoes capazes de satisfazer a pesquisa, estas sao adiciona-

das ao resultado da pesquisa. Apos o processamento de todos os fragmentos no Arquivo LdoD, o

servico instancia uma vista apresentado as interpretacoes agrupadas por fragmentos e o valor que a

interpretacao possui para todos os criterios da pesquisa sobre a forma de uma tabela e envia para o

cliente. O SearchController instancia um objeto Search com uma lista de SearchOption. As SearchOp-

tions representam os varios opcoes que o utilizador adicionou a sua pesquisa. A Figura 7.5 planifica o

visitor da opcao classe SearchOption e define a interface para o processamento de especializacoes de

interpretacoes.

Figura 7.5: Diagrama de classes do visitor abstrato.

No Arquivo LdoD, estao implementadas as opcoes referentes a inclusao nas edicoes de peritos,

existencia de fontes manuscrita, datilografada e publicada, heteronimia, datacao, presenca de taxono-

mias e inclusao em edicoes virtuais. A Figura 7.6 apresenta as opcoes referentes ao heteronimo, data,

texto, fontes publicadas, taxonomias e inclusao em edicoes virtuais

59

Figura 7.6: Diagrama de classes de implementacoes de opcoes.

A opcao referente a inclusao na edicao de peritos encontra-se explicitada na Figura 7.7. Nesta

podemos observar a reutilizacao da classe HeteronymSearchOption e DateSearchOption que refinam

a inclusao nas edicoes crıticas quanto ao heteronimo e data atribuıda pelo editor.

Figura 7.7: Diagrama de classes da inclusao nas edicoes de peritos.

A Figura 7.8 mostra o processamento de interpretacoes de fontes autorais. As interpretacoes de

fonte manuscrita e a fonte datilografada sao analogas, deste modo, a classe AuthoralSearchOption im-

plementa o processamento, deixando em apenas em aberto a identificacao do tipo de fonte. Esta e

encontrada atraves da definicao de um template method. Este metodo e implementado pelas classes

ManuscriptSearchOption, identificando as interpretacoes de fontes autorais manuscritas e Typescritp-

SearchOption, que identifica as fontes autorais datilografadas.

60

Figura 7.8: Diagrama de classes das fontes autorais manuscritas e datilografas.

A visao geral da pesquisa encontra-se na Figura A.1, onde encontramos todas as classes capazes

de representar as varias opcoes de pesquisa.

Para alem de apresentar a implementacao das opcoes descritas na Seccao 6.1.2, este diagrama

tambem introduz o mote para a implementacao de novas opcoes. O processamento da pesquisa execu-

tado no SearchController para depurar se um fragmento satisfaz a pesquisa e agnostico, isto e, apenas

interage com a classe SearchOption. A introducao de futuras pesquisas sera feita segundo uma meto-

dologia analoga a usada para implementar as opcoes em vigor na aplicacao, nao introduzindo qualquer

tipo de complexidade adicional ao processamento efetuado no SearchController.

7.4 Sistema de Recomendacao

A heurıstica que orienta o sistema de recomendacao e a sua alta modularidade e flexibilidade. Deste

modo estabeleceram-se duas classes no sistema de recomendacao com papeis e responsabilidades

distintas. O Recommender e a classe do sistema cuja responsabilidade e proporcionar uma interface

com um conjunto de operacoes para a identificacao do grau de semelhanca entre itens. A Property e

a classe do sistema que esta encarregue de processar itens e produzir uma estrutura de informacao

capaz de ser processada pelo Recommender, determinando o grau de semelhanca entre os itens.

Esta separacao clara ira permitir a implementacao de Recommenders concretos, que seguem uma

metrica de implementacao e aceitam um tipo de propriedades. Portanto, a partir desta conjugacao e

possıvel criar Recommenders para recomendar fragmentos, interpretacoes, edicoes, fontes, taxono-

mias, utilizadores, ou qualquer outra entidade do domınio. Por outro lado, e possıvel criar propriedades

que processem qualquer uma dessas entidades do domınio.

61

Figura 7.9: Diagrama de classes do Recommender.

A Figura 7.9 apresenta assim a interface do Recommender, estabelecendo as operacoes base que

o sistema de recomendacao oferece. As operacoes prendem-se com calcular o grau de semelhanca

entre dois itens do domınio segundo um criterio ou um conjunto de criterios, satisfazem a combinacao

de criterios pretendida atraves da colecao de propriedades que aceita. Encontrar o item com maior grau

de semelhanca de um conjunto de itens, segundo um criterio ou um conjunto de criterios. Tambem

possibilita a obtencao de uma lista de pares de itens e grau de semelhanca ordenada pelo grau de

semelhanca, em relacao ao item de referencia, a partir de um conjunto de itens segundo um ou mais

criterios. A flexibilidade e atingida atraves do uso de generics. De notar que T endereca uma entidade

do domınio que se pretende recomendar e P uma hierarquia de classes capazes de processar T.

A implementacao efetuada no ambito desta dissertacao, retrata um Recommender baseado em

VSM onde os itens sao analisados e produzem vetores que representam as suas caracterısticas. O

VSMRecommender, apresentado tambem na Figura 7.9, trata-se de uma implementacao do Recom-

mender atraves de VSM onde a classe abstrata Property estabelece uma interface para o processa-

mento de itens e modelacao da suas propriedades em vetores de propriedades, aqui apresentados

como uma lista de doubles. O grau de semelhanca entre os itens e calculado atraves de coisine si-

milarity entre os vetores de propriedades. A biblioteca JAMA [31] auxilia a esta operacao facultando

funcoes para o calculo do produto escalar e produto vetorial.

62

Figura 7.10: Diagrama de classes do VSMFragInterRecommender e VSMFragmentRecommender.

O VSMFragInterRecommender, apresentado na Figura 7.10 foi uma das das implementacoes con-

cretas produzidas com o intuito de recomendar interpretacoes atraves da hierarquia de Property. Este

e o Recommender que o Arquivo usa para produzir as recomendacoes para a navegacao, ordenacao

de edicoes e ordenacao encaixada. O VSMFragmentRecommender e outro Recommender criado no

contexto desta dissertacao a tıtulo experimental com o objetivo de demonstrar a capacidade da arquite-

tura do sistema de recomendacao em produzir novos Recommenders. Este e um Recommender para

fragmentos suportado pela hierarquia de Property.

Mais uma vez a preocupacao quando a introducao de novas propriedades e tida em conta, tal

como nas pesquisas. O sistema de recomendacao sera orientado para processar um fragmento e

obter um vetor de propriedades. Com essa finalidade a abstracao e crucial, garantido que o sistema

de recomendacao apenas interage com um conceito abstrato de propriedade, capaz de transformar um

fragmento ou interpretacao num vetor de propriedades. Assim sendo, a propriedade abstrata introduzira

uma interface usada pelo sistema de recomendacao.

A concretizacao sera entao implementada por propriedades capazes de processar fragmentos e

interpretacoes, produzindo vetores que refletem as propriedades apresentadas anteriormente. As-

sim sendo, a introducao de novas propriedades e respetivo processamento para vetores, nao implica

alteracoes na arquitetura e implementacao do sistema de recomendacao.

A identificacao do tipo de interpretacao que se esta a processar e feito em tempo de execucao,

recorrendo a um visitor capaz de identificar o tipo de interpretacao a processar, selecionando a rotina

capaz de produzir o vetor de propriedades apropriado para aquele tipo de interpretacao, este encontra-

se planificado em maior detalhe na Figura 7.10.

Tal como mencionado anteriormente, a hierarquia de Property e responsavel por processar os ele-

63

mentos de domınio e produzir vetores de propriedades. Esta hierarquia e especialmente orientada ao

processamento de todas as interpretacoes de um fragmento. A classe abstrata Property pretende sa-

tisfazer essa necessidade, definindo um visitor capaz identificar em tempo de execucao a entidade do

domınio que esta a processar. A classe Property torna-se assim numa abstracao completa das varias

implementacoes de propriedades, permitindo o uso de propriedades por parte do VSMFragInterRecom-

mender sem necessitar de conhecer as implementacoes. O metodo visit tambem define um template

method para as futuras implementacoes atraves do metodo protected extractVector para os varios tipos

de interpretacoes e para fragmentos. Este metodo e capaz de processar interpretacoes e fragmentos e

produzir vetores que expressam as propriedades segundo a exposicao feita no Capıtulo 3. As classes

que estendam Property implementam o metodo extractVector para processar a entidade do domınio

desejada, sejam elas interpretacoes ou fragmentos. De notar a presenca do atributo weight que pre-

tende ser o valor a colocar nas posicoes do vetor que representem uma caracterıstica que o item possui

ou zero quando o item nao manifesta a propriedade. Por omissao, o atributo weight e instanciado com

o valor 1, espelhando a abordagem binaria encontrada com frequencia na literatura.

Figura 7.11: Diagrama de classes de implementacoes das propriedades textuais e taxonomicas.

Na Figura 7.11 temos a implementacao das propriedades textuais e taxonomicas. A SpecificTa-

xonomyProperty implementa a comparacao entre categorias de taxonomias. Esta so implementa a

extracao do vetor de propriedades taxonomicas, no entanto deixa em aberto a definicao do valor a

colocar em cada posicao do vetor que represente uma categoria encontrada na interpretacao, atraves

da instauracao de um template method. Este metodo e implementado pelas classes que a esten-

64

dem, a BinaryTaxonomyProperty e WeightTaxonomyProperty. A BinaryTaxonomyProperty implementa

uma estrategia binaria, onde a existencia da categoria se traduz no valor 1 na posicao do vetor que

a representa. Por outro lado, a WeightTaxonomyProperty devolve o peso da categoria para aquela

interpretacao e coloca-o na posicao do vetor que a representa.

Figura 7.12: Diagrama de classes da StorableProperty.

A Figura 7.12 apresenta as implementacoes para data, heteronimo, inclusao nas edicoes de peritos

e fontes autorais, tal como descrito na Seccao 6.4.2. Aqui tambem introduzimos a classe Compo-

siteProperty, criada com o objetivo de refatorizar codigo, pois a EditionProperty e a SourceProperty

delegam parte da geracao do seu vetor na HeteronymProperty e DateProperty.

As caracterısticas dos fragmentos e interpretacoes que estao descritos na Seccao 3.1 tem uma

natureza estatica, sendo apenas alterados pela alteracao do ficheiro TEI e consequente carregamento

para arquivo. Deste modo, a StorableProperty pretende fornecer uma estrategia para guardar os ve-

tores produzidos por propriedades que implementam as caracterısticas apresentadas na Seccao 3.1.

Ao implementar os metodos visit, este redefine o comportamento das propriedades quando estao a

processar um item. A Property implementa um metodo visit que simplesmente invoca o metodo extract-

Vetor, por outro lado a classe StorableProperty redefine este comportamento, verificando primeiro se a

propriedade e o item ja foram processado, determinado se o vetor de propriedades ja foi encontrado.

Caso ainda nao tenha sido encontrado, o metodo extractVector e invocado e o vetor de propriedades e

65

guardado num tuplo antes de devolver o vetor. O tuplo contem o identificador da propriedade, atraves do

nome da classe da propriedade, o identificador do item, atraves do ExternalId da entidade do domınio,

e o vetor de propriedades. Assim sendo, o vetor so e calculado da primeira vez que a propriedade esta

a processar o item, e nos futuros processamentos, o vetor e devolvido sem que haja a necessidade de

o voltar calcular.

O sistema de recomendacao pode ser visualizado na sua totalidade na Figura A.2.

Seguindo a logica do modelo apresentado, a complexidade de implementacao de um Recommender

baseado em VSM de edicoes virtuais e reduzida, assim como e a implementacao de Properties capa-

zes de processar edicoes virtuais. Para atingir este fim, estenderıamos a classe VSMRecommender,

fazendo o binding do T para VirtualEdition, introduzindo o metodo visit para VirtualEdition e definindo

uma forma de comparar edicoes virtuais numa subclasse de Property, tal como apresentado na Fi-

gura 7.13. O desafio desta extensao reside na identificacao de propriedades das edicoes virtuais e na

sua planificacao sobre a estrutura vetorial, um exercıcio analogo ao efetuado na Seccao 6.4.2.

Figura 7.13: Diagrama de classes do sistema de recomendacao para edicoes virtuais.

7.5 Alteracoes ao Domınio

Nesta seccao relataremos as alteracoes efetuadas ao domınio da FenixFramework no decorrer

desta dissertacao.

7.5.1 Guardar as Preferencias do Utilizador

O utilizador pode definir o peso que quer atribuir a cada propriedade, espelhando o grau de re-

levancia que da a cada uma delas e que orientarao a recomendacao na producao de recomendacoes

66

para a navegacao e na ordenacao de edicoes virtuais. Estes pesos sao usados para configurar as pro-

priedades, definindo o weight da propriedade no momento da sua instanciacao. Deste modo o utilizador

podera definir a importancia de cada uma das propriedades na determinacao do grau de semelhanca.

Visto que as recomendacoes serao feitas no ambito de uma edicao virtual, o modelo do domınio foi

expandido para conter uma entidade cuja responsabilidade e guardar as preferencias do utilizador de

forma permanente.

A classe RecommendationWeights e TaxonomyWeight espelham esta necessidade na Figura 7.14

e as respetivas relacoes com o utilizador, edicao virtual e taxonomias.

Figura 7.14: Diagrama de entidades com as preferencias do utilizador.

O modelo de domınio do Arquivo LdoD e gerido pela FenixFramework, deste modo a Domain Mo-

delling Language (DML) foi atualizada com as alteracoes especificadas na Figura B.1. A classe Recom-

mendationWeights contem os pesos que o utilizador deu a cada uma das propriedades transversais a

todas as edicoes virtuais. A classe TaxonomyWeight pretende conter o peso que o utilizador atribuiu a

cada uma das taxonomias associadas a uma edicao virtual.

7.5.2 Adicionar Seccoes a Edicoes Virtuais

A ordenacao encaixada produz uma edicao com seccoes com uma semantica propria. Cada ele-

mento de uma seccao tem exatamente o mesmo grau de semelhanca com o item selecionado pelo

utilizador. Com o objetivo de introduzir seccoes no arquivo, alterou-se o modelo de domınio tal como

exemplificado na Figura 7.15, introduzindo a entidade Section. Esta entidade altera a semantica de

uma edicao. Na Figura 2.1 temos a edicao virtual como uma composicao de edicoes virtuais. Agora

uma edicao virtual e uma composicao de seccoes. Por sua vez, cada seccao pode conter mais seccoes

ou interpretacoes virtuais.

67

Figura 7.15: Diagrama de entidades com seccoes.

A seccao e as relacoes que foram introduzidas na DML para permitir este comportamento das

edicoes virtuais encontra-se espelhado na Figura B.2.

7.6 Navegacao por Recomendacoes

Quando o utilizador visualiza uma fragmento, ou uma interpretacao de um fragmento, a vista e

parametrizada para que cada edicao virtual do utilizador apresenta uma ligacao para o fragmento com

maior grau de semelhanca. Quando a vista e parametrizada, e pedido ao VSMFragInterRecomender

que identifique o fragmento com maio grau de semelhanca de todos os fragmentos da edicao virtual

face ao fragmento que esta a ser visualizado.

Sempre que o utilizador iniciar uma navegacao por recomendacao e enquanto estiver a viajar por

recomendacao dentro da mesma edicao, os fragmentos que ja visitou no contexto desta consulta sao

mantidos no formulario da pagina e enviados ao servidor quando se pretende viajar para o proximo frag-

mento recomendado. Os fragmentos previamente visitados sao retirados do conjunto de fragmentos da

edicao virtual antes de produzir uma recomendacao, impedido que fragmentos previamente recomen-

dados voltem a ser sugeridos. Isto e, a navegacao por recomendacao nao tem estado representativo

do lado do servidor.

7.7 Ordenacao de Edicoes

A ordenacao de edicoes pode ser despontada por duas acoes do utilizador. Sempre que o utilizador

selecionar uma nova interpretacao virtual de um fragmento da edicao virtual, e efetuado um pedido

Ajax ao RecommendationController com a indicacao do fragmento selecionado. O Recommendation-

Controller recolhe os pesos do utilizador da FenixFramework e instancia subclasses de Property para

68

expressar os esses pesos. De seguida passa a interpretacao virtual, a lista de interpretacoes virtuais

da edicao virtual e a lista de propriedades ao VSMFragInterRecommender. Este produz uma lista or-

denada de interpretacoes pelo grau de semelhanca e materializa-a numa JavaServer Pages (JSP) que

devolve a apresentacao.

Quando o utilizador altera a relevancia que pretende dar a cada criterio atraves da modificacao do

peso desta, expressado pelo seu slider, a apresentacao invoca o RecommendationController atraves

de Ajax com informacao dos novos pesos e qual e a interpretacao virtual que se encontra em primeiro

na edicao virtual. O processamento efetuado no RecommendationController e semelhante ao descrito

anteriormente, no entanto tem uma etapa preliminar onde os pesos do utilizador sao atualizados.

Apos uma reordenacao, surgem dois elementos na interface, um para gravar a ordenacao atual e

outro para criar uma nova edicao com com a configuracao atual. Gravar a edicao virtual efetua um

pedido Ajax com a ordenacao demonstrada, o RecommendationController trata de ordenar a edicao e

envia uma tabela parametrizada a partir de um JSP com a nova ordenacao, que a apresentacao trata de

expor. Criar uma nova edicao e feito com recurso a um POST, onde e enviada a ordenacao que esta a

ser apresentada. O RecommendationController reordena a edicao e devolve a vista com a planificacao

da nova edicao virtual. A Figura 7.16 apresenta as iteracoes e trocas de mensagens descritas.

Figura 7.16: Diagrama de interacao da ordenacao de edicoes.

69

Figura 7.17: Interface da ordenacao de edicoes.

A Figura 7.17 apresentada a interface criada para a ordenacao de edicoes, seguindo o conceito

apresentado na Seccao 5.4.

7.8 Ordenacao Encaixada de Edicoes

A ordenacao encaixada e semelhante a ordenacao de edicoes, sendo despontada pelas mesmas

acoes. Neste caso, para alem de enviar os pesos a usar, e sempre necessario enviar a iteracao em que

se pretende usar o criterio. A escolha da interacao e feita atraves da manipulacao do slider, arrastando

a propriedade para a iteracao em que devera ser usada. A interacao descrita foi atingida com recurso a

biblioteca jQuery UI [32]. Deste modo, e enviado no Ajax um mapa onde a chave e a iteracao e o valor

uma lista de criterios a usar, com o respetivo peso. O RecommendationController atualiza os pesos e

recolhe a lista de interpretacoes da edicao virtual, tal como na ordenacao. A interpretacao selecionada,

lista de interpretacoes da edicao virtual, mapa com as iteracoes e respetivas interpretacoes sao passa-

dos para o VSMFragInterRecommender. Este comeca por instanciar um Cluster onde estao todas as

interpretacoes, tal como indicado no diagrama de classes da Figura 7.18.

Figura 7.18: Diagrama de classes da ordenacao encaixada.

De seguida comeca a separar as interpretacoes em clusters segundo o grau de semelhanca para

a interpretacao selecionada segundo as propriedades indexadas a primeira iteracao. Para cada um

dos clusters criados, volta a aplicar a separacao recorrendo as propriedades da segunda iteracao.

70

O processo e repetido ate que todas as iteracoes tenham terminado. O resultado e uma estrutura

em arvore, em que as interpretacoes estao nas folhas e cada cluster intermedio indica o grau de

semelhanca de todos os seus filhos. Esta estrutura em arvore e entao passada a uma vista JSP e

devolvida para a apresentacao.

Figura 7.19: Diagrama de interacao da ordenacao encaixada.

Tanto as acoes de guardar como criar uma nova edicao enviam a ordenacao gerada com indicacao

da seccao onde se encontram. O RecommendationController instancia a hierarquia de seccoes, co-

locando as interpretacoes nas folhas certas. Tal como ordenacao, ao gravar a edicao apresentada e

actualizado atraves da parametrizacao de uma vista e criacao de uma nova edicao, remetendo para

uma vista onde a nova edicao e apresentada. A interacao e apresentada na Figura 7.19, e semelhante

a interacao anterior, adicionando apenas nova acao que provoca a ordenacao quando o utilizador altera

a configuracao das iteracoes.

71

Figura 7.20: Interface da ordenacao encaixada.

A Figura 7.20 apresenta a interface construıda com o auxılio de jQuery UI [32], permitindo que o

utilizador arraste a propriedade para o passo desejado. Assim sendo, cada linha representa um passo

da ordenacao encaixada na qual serao aplicados as propriedades que se encontram nessa linha.

72

8Conclusao

Contents8.1 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748.2 Desenvolvimentos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

73

8.1 Conclusao

No ambito das funcionalidades acordadas com a equipa do LdoD, considera-se que foram imple-

mentadas, satisfazendo as suas expetativas tracadas para a vertente livro do arquivo. A solucao en-

contrada para as pesquisas e recomendacoes cumprem nao so as expetativas, como foi construıda de

modo a potenciar a implementacao de novas opcoes e criterios de recomendacao, seguindo a heurıstica

de desenvolvimento estabelecida para a construcao dos sistemas, com o intuito de potenciar a extensao

do modelo para a inclusao de novas funcionalidades num dos ambitos.

8.2 Desenvolvimentos Futuros

O futuro deste trabalho estara sempre ligado ao desenvolvimento de novas opcoes de pesquisa,

capazes de quantificar a evolucao do projeto e introducao de informacao. Ao nıvel das recomendacoes,

tambem temos a introducao de novos criterios de recomendacao resultantes da evolucao da aplicacao.

A evolucao espera-se que seja principalmente na dimensao virtual. Desta evolucao teremos a

criacao natural de um sistema de recomendacoes orientado agora as edicoes virtuais, pois o numero de

edicoes virtuais crescera proporcionalmente com numero de utilizadores e longevidade da aplicacao. O

crescimento tambem podera dar origem a criacao de um sistema de recomendacao baseado em filtros

colaborativos para recomendar edicoes virtuais, no entanto este so podera ser concretizado quando se

atingir um volume consideravel de utilizadores e edicoes virtuais.

Acompanhar a evolucao do projeto e outra das ambicoes, este objetivo encontra-se facilitado pela

natureza open source do projeto e facil acesso ao seu repositorio, que se encontra em https://github.

com/socialsoftware/edition.

74

Referencias

[1] M. Portela, “Nenhum problema tem solucao: Um arquivo digital do Livro do Desassossego,” Estra-

nhar Pessoa com as Materialidades da Literatura, 2013.

[2] A. R. Silva and M. Portela, “Tei4ldod: Textual encoding and social editing in web 2.0 environments,”

Journal of the Text Encoding Initiative [Online], vol. 8, 2015.

[3] ——, “Social edition 4 the book of disquiet: The disquiet of experts with common users,” in Confe-

rence: 13th European Conference on Computer-Supported Cooperative Work, 2013.

[4] M. Portela and A. R. Silva, “A model for a virtual ldod,” Literary and Linguistic Computing Advance

Access, 2014.

[5] “TEI: Text Encoding Initiative,” http://www.tei-c.org/index.xml, 2007.

[6] “Fenix Framework,” https://fenix-framework.github.io.

[7] “Spring MVC Framework,” https://spring.io.

[8] “jQuery,” https://jquery.com.

[9] “Bootstrap - The world’s most popular mobile-first and responsive front-end framework,” http:

//getbootstrap.com.

[10] G. Salton, A. Wong, and C. Yang, “A vector space model for automatic indexing,” Communications

of the ACM, vol. 18, no. 11, pp. 613–620, 1975.

[11] G. Salton, The SMART Retrieval System - Experiments in Automatic Document Processing. Upper

Saddle River, NJ, USA: Prentice-Hall, Inc., 1971.

[12] M. D. Ekstrand, J. T. Riedl, and J. A. Konstan, “Collaborative filtering recommender systems,”

Found. Trends Hum.-Comput. Interact., vol. 4, no. 2, pp. 81–173, Feb. 2011. [Online]. Available:

http://dx.doi.org/10.1561/1100000009

[13] A. Rajaraman and J. D. Ullman, Mining of Massive Datasets. New York, NY, USA: Cambridge

University Press, 2011.

[14] “Stack Overflow,” https://stackoverflow.com.

[15] “Awesome Wallpapers,” http://alpha.wallhaven.cc.

75

[16] L. von Ahn, S. Ginosar, M. Kedia, R. Liu, and M. Blum, “Improving accessibility of the web with

a computer game,” in Proceedings of the SIGCHI Conference on Human Factors in Computing

Systems, ser. CHI ’06. New York, NY, USA: ACM, 2006, pp. 79–82. [Online]. Available:

http://doi.acm.org/10.1145/1124772.1124785

[17] R. V. Meteren and M. V. Someren, “Using content-based filtering for recommendation,” in Workshop

on Machine Learning in the New Information Age, 2000, pp. 312–321.

[18] T. Yan and H. Garcia-Molina, “Index structures for information filtering under the vector

space model,” Stanford Infolab, Technical Report 1993-11, 1993. [Online]. Available:

http://ilpubs.stanford.edu:8090/18/

[19] M. Balabanovic and Y. Shoham, “Fab: Content-based, collaborative recommendation,” Commun.

ACM, vol. 40, no. 3, pp. 66–72, Mar. 1997. [Online]. Available: http://doi.acm.org/10.1145/245108.

245124

[20] P. Lops, M. de Gemmis, and G. Semeraro, “Content-based recommender systems: State

of the art and trends.” in Recommender Systems Handbook, F. Ricci, L. Rokach,

B. Shapira, and P. B. Kantor, Eds. Springer, 2011, pp. 73–105. [Online]. Available:

http://dblp.uni-trier.de/db/reference/rsh/rsh2011.html#LopsGS11

[21] B. D. Sheth, “A learning approach to personalized information filtering,” Massachusetts Institute of

Technology, Tech. Rep., 1994.

[22] A. Oord, S. Dieleman, and B. Schrauwen, “Deep content-based music recommendation,” in

Advances in Neural Information Processing Systems 26, C. Burges, L. Bottou, M. Welling,

Z. Ghahramani, and K. Weinberger, Eds. Ghent University, 2013, pp. 2643–2651. [Online].

Available: http://media.nips.cc/nipsbooks/nipspapers/paper files/nips26/1239.pdf

[23] G. Adomavicius and A. Tuzhilin, “Toward the next generation of recommender systems: A survey

of the state-of-the-art and possible extensions,” IEEE Trans. on Knowl. and Data Eng., vol. 17,

no. 6, pp. 734–749, Jun. 2005. [Online]. Available: http://dx.doi.org/10.1109/TKDE.2005.99

[24] A. M. Rashid, I. Albert, D. Cosley, S. K. Lam, S. M. McNee, J. A. Konstan, and J. Riedl, “Getting to

know you: Learning new user preferences in recommender systems,” in Proceedings of the 7th

International Conference on Intelligent User Interfaces, ser. IUI ’02. New York, NY, USA: ACM,

2002, pp. 127–134. [Online]. Available: http://doi.acm.org/10.1145/502716.502737

[25] B. Sarwar, G. Karypis, J. Konstan, and J. Riedl, “Item-based collaborative filtering recommendation

algorithms,” in Proceedings of the 10th International Conference on World Wide Web,

ser. WWW ’01. New York, NY, USA: ACM, 2001, pp. 285–295. [Online]. Available:

http://doi.acm.org/10.1145/371920.372071

[26] G. Linden, B. Smith, and J. York, “Amazon.com recommendations: Item-to-item collaborative

filtering,” IEEE Internet Computing, vol. 7, no. 1, pp. 76–80, Jan. 2003. [Online]. Available:

http://dx.doi.org/10.1109/MIC.2003.1167344

76

[27] B. M. Sarwar, G. Karypis, J. Konstan, and J. Riedl, “Recommender systems for large-scale e-

commerce: Scalable neighborhood formation using clustering,” 2002.

[28] A. Hannak, P. Sapiezynski, A. Molavi Kakhki, B. Krishnamurthy, D. Lazer, A. Mislove, and

C. Wilson, “Measuring personalization of web search,” in Proceedings of the 22Nd International

Conference on World Wide Web, ser. WWW ’13. Republic and Canton of Geneva, Switzerland:

International World Wide Web Conferences Steering Committee, 2013, pp. 527–538. [Online].

Available: http://dl.acm.org/citation.cfm?id=2488388.2488435

[29] “Apache Lucene,” https://lucene.apache.org.

[30] “Riot.js — A React-like user interface micro-library,” http://riotjs.com.

[31] “JAMA: Java Matrix Package,” http://math.nist.gov/javanumerics/jama.

[32] “jQuery UI,” https://jqueryui.com.

[33] “Jackson JSON Processor,” https://github.com/FasterXML/jackson.

[34] D. Lemire and A. Maclachlan, “Slope one predictors for online rating-based collaborative

filtering,” in Proceedings of SIAM Data Mining (SDM’05), 2005. [Online]. Available: http:

//www.daniel-lemire.com/fr/documents/publications/lemiremaclachlan sdm05.pdf

[35] J. Bennett and S. Lanning, “The netflix prize,” in Proceedings of the KDD Cup Workshop

2007. New York: ACM, Aug. 2007, pp. 3–6. [Online]. Available: http://www.cs.uic.edu/∼liub/

KDD-cup-2007/NetflixPrize-description.pdf

[36] G. Salton, Automatic Text Processing: The Transformation, Analysis, and Retrieval of Information

by Computer. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1989.

[37] D. Billsus and M. J. Pazzani, “User modeling for adaptive news access,” User Modeling

and User-Adapted Interaction, vol. 10, no. 2-3, pp. 147–180, Feb. 2000. [Online]. Available:

http://dx.doi.org/10.1023/A:1026501525781

77

78

ADiagramas de classes

A-1

Figura A.1: Diagrama de classes da pesquisa.A-2

Figura A.2: Diagrama de classes do sistema de recomendacao.A-3

BDML

B-1

class RecommendationWeights {

double editionWeight;

double heteronymWeight;

double dateWeight;

double manuscriptWeight;

double typescriptWeight;

double publicationWeight;

double textWeight;

double sourceWeight;

}

relation LdoDUserHasRecommendationWeights {

LdoDUser playsRole user {multiplicity 1..1;}

RecommendationWeights playsRole recommendationWeights {multiplicity 0..*;}

}

relation VirtualEditionHasRecommendationWeights {

VirtualEdition playsRole virtualEdition {multiplicity 1..1;}

RecommendationWeights playsRole recommendationWeights {multiplicity 0..*;}

}

class TaxonomyWeight {

double weight;

}

relation RecommendationWeightsHasTaxonomyWeight {

RecommendationWeights playsRole recommendationsWeights {multiplicity 1..1;}

TaxonomyWeight playsRole taxonomyWeight {multiplicity 0..*;}

}

relation TaxonomyHasTaxonomyWeight {

Taxonomy playsRole taxonomy {multiplicity 1..1;}

TaxonomyWeight playsRole taxonomyWeight {multiplicity 0..*;}

}

Figura B.1: DML dos pesos do utilizador.

class Section {

String title;

int number;

}

relation VirtualEditionHasSections {

VirtualEdition playsRole virtualEdition {multiplicity 0..1;}

Section playsRole sections {multiplicity 1..*;}

}

relation SectionHasSections {

Section playsRole parentSection {multiplicity 0..1;}

Section playsRole subSections {multiplicity 0..*;}

}

relation SectionHasVitualEditionInters {

Section playsRole section {multiplicity 1..1;}

VirtualEditionInter playsRole VirtualEditionInter {multiplicity 0..*;}

}

Figura B.2: DML das seccoes.

B-2