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
Top Related