<div class="alert alert-warning"> <p><strong>O código fonte deste projecto pode ser obtido <a target="_blank" href="https://bitbucket.org/lfac/saraivas-fine-series">aqui</a>.</strong> </p> <p>Para utilizar a aplicação basta instalar a <a target="_blank" href="http://www.playframework.org/">framework Play</a> (tem que ser uma versão <strong>anterior à 2.0</strong>, qualquer uma das versões <strong>1.x.x</strong> serve sendo que a aplicação foi desenvolvida na versão <strong>1.2.4</strong>), ir ao directório da aplicação e correr o comando <code>play run</code>. Se nada tiver sido alterado nos ficheiros de configuração a aplicação pode nesse momento ser acedida pelo endereço http://localhost:9000 .</p> </div>  # Objetivos do Projeto Os objetivos deste projeto podem-se separar em três categorias: navegação, procura e recomendação. Ao abordarmos cada um destes requisitos base foram criados requisitos mais específicos que correspondem a funcionalidades bem definidas. ## Navegação 1.1 Dado um id válido de ator mostrar toda a informação disponível sobre o mesmo numa página web dedicada. 1.2 Dado um id válido de criador mostrar toda a informação disponível sobre o mesmo numa página web dedicada. 1.3 Dado um id válido de personagem mostrar toda a informação disponível sobre a mesma numa página web dedicada. 1.4 Dado um id válido de série mostrar toda a informação disponível sobre a mesma numa página web dedicada. 1.5 Fazer a listagem completa de séries, atores, criadores, anos, géneros e tags. 1.6 Permitir a navegação via clique em referências a anos, géneros, tags, criadores, atores, séries e personagens. ## Procura 2.1 Pesquisa sintática baseada em número de ocorrências das palavras na query. 2.2 Funcionalidade por defeito da pesquisa semântica: tentar fazer matching da query a um nome de uma instância de série, ator, personagem ou criador. 2.3 Estender 2.2 permitindo definir a classe que se pretende. 2.4 Estender 2.3 permitindo definir um filtro por predicado. 2.5 Estender 2.4 permitindo definir um filtro num intervalo (para os campos em que se aplique) 2.6 Estender 2.3 permitindo especificar uma outra classe (que terá de estar relacionada com a primeira). Os resultados da procura serão todas as instâncias da segunda classe que se relacionem com as instâncias da primeira. Por exemplo todos os atores da série XYZ. 2.7 Tornar o matching de nomes de classes e predicados mais user-friendly não considerando a capitalização e permitindo palavras semelhantes (por exemplo: series ser interpretado como TVSeries). 2.8 Permitir internacionalização com base em anotações definidas na ontologia. ## Recomendação 3.1 Fazer recomendações com base no histórico de navegação do utilizador. 3.2 Ter uma estratégia de fall-back para o caso de utilizadores sem histórico. 3.3 Permitir ver diretamente (sem abrir outra página) informação relevante sobre as séries recomendadas (por exemplo: título e rating) 3.4 Ter uma vista dedicada que permita navegar visualmente todas as séries existentes na ontologia. 3.5 Estender 3.4 permitindo filtrar por ano e rating. # Abordagem e Arquitetura Nesta secção é descrita a abordagem seguida, o desenho das soluções, o design da arquitetura e são explicadas as decisões tomadas. ## Tecnologias  ## Ontologia A ontologia apresentada foi implementada de raiz uma vez que não encontrámos nenhuma que considerássemos adequada para reutilização. Por exemplo, a Programmes Ontology (BBC, 2009) está relacionada com o nosso tema, mas aprofunda muitos conceitos sem interesse neste contexto como meio (canal de comunicação) e acabaria por ser muito mais complexa que o necessário. O namespace escolhido para a ontologia foi: http://www.semanticweb.org/ontologies/2011/9/WSTV.owl#. A ontologia foi criada no protégé versão 4.1.0 e foi extraída no formato RDF/XML.  Esta ontologia tem como classe mais importante TVSeries que contém seasons que por sua vez contêm episodes. TVSeries pode ainda ter uma ou mais tags criadas por users, um ou mais géneros e uma ou mais reviews criadas também por users. Esta classe tem ainda criadores, atores e personagens representadas por atores. A classe Genre tem como subclasses todos os géneros que são contemplados nas séries guardadas no nosso sistema. Já as instâncias de Tag têm a propriedade hasTagName, que é uma data property com range string. A razão desta distinção baseia-se na consideração de que o número de géneros possíveis que faz sentido contemplar é finito (ao contrário do número de tags) e como tal parece-nos mais correto contemplá-los como classes na ontologia, uma vez que não só fica explícito e automaticamente visível o que consideramos géneros, mas fica também controlado quando se acrescentam géneros. Por outro lado, podem existir várias tags escritas de várias formas diferentes que na realidade são equivalentes (devido à existência de sinónimos, diferentes perceções de questões muito subjetivas e mesmo devido a erros ortográficos) o que causa uma fragmentação de entidades que na realidade pertencem ao mesmo grupo lógico dentro do contexto. Este sistema de classificação por tags é uma folksonomy e como tal tem as mesmas vantagens e desvantagens destes métodos colaborativos. O mesmo não acontece com géneros que são melhor controlados e são finitos. Assim, há uma maior ponderação no conjunto de géneros que o mantém controlado e finito. Isto é, evita-se que estes cresçam sem controlo e que sejam dados vários nomes diferentes a algo que seja o mesmo género, uma vez que este tem que existir na ontologia para ser atribuído. Uma Person pode ser User, Actor, Creator e Character. Consideramos que User é disjunta de todos. Especificamente é importante apontar que consideramos um User disjunta de Actor e Creator porque as entidades ator e criador são mantidas pela aplicação e não pelas próprias pessoas. Contudo, um Creator pode ser também Actor logo estas classes não são disjuntas entre si. Adicionalmente, consideramos que Character pode ser interpretado por mais do que um Actor uma vez que tal é possível. Em alguns casos são utilizadas anotações na ontologia para esclarecer alguns detalhes. São usadas ainda anotações com tag de língua (por exemplo “”@pt) para auxiliar a implementação de pesquisas multilíngue utilizando as funcionalidades específicas do SPARQL para queries desta natureza. Utilizámos ainda o design pattern Value Partition para refinar a descrição da classe TVSeries. A nossa RatingsValuePartition restringe os possíveis valores de quão boa é uma série em: Good, Medium ou Bad de acordo com a sua nota. Uma TVSeries vai ter um destes valores e, como já se deve ter tornado aparente, a escolha é mutuamente exclusiva. Dando uso a esta RatingsValuePartition criámos uma subclasse de TVSeries denominada de GoodTVSeries, que tem séries que têm boa nota. Criámos ainda uma subclasse de TVSeries, InterestingTVSeries, que contém séries que satisfazem as condições: + Ser subclasse de TVSeries. + Possuir mais de 30.000 avaliações (nota atribuída por utilizadores). + Possuir mais de 100 revisões. É importante notar, que apesar de termos as restrições definidas na ontologia criada no protégé, estas são na realidade mantidas pela aplicação aquando a população da ontologia. Refere-se ainda que seria possível obter esta mesma informação por queries SPARQL, mas considerámos que assim ficaria mais explícito o que consideramos séries boas e séries interessantes e permitiu-nos experimentar algumas funcionalidades do protégé e ainda simplificar algumas queries SPARQL que sabíamos que pretendíamos utilizar bastante no futuro. O tutorial de ontologia de pizzas do protégé (Horridge, 2011) desaconselha, de forma geral, a especificação de domains e ranges de propriedades, uma vez que estas condições não se comportam como restrições e podem causar resultados de classificação “inesperados”. No entanto, a nossa ontologia não é muito grande logo não seria difícil descobrir efeitos secundários desta escolha e, desta forma, consideramos que compensa ter esta informação valiosa para alguém que queira perceber a ontologia. Adicionalmente, o facto de estarmos a trabalhar numa área que está na vanguarda tecnológica leva-nos a considerar que é possível a evolução e futura criação de novas features que permitam tirar valor de escolhas que neste momento não são aproveitadas pelas ferramentas em uso. Adicionalmente, apesar de a ontologia ter sido exportada para RFD/XML, e por isso perder qualquer característica que não seja fosse possível representar neste formato, decidimos definir características que só existem em OWL. Claro que algumas destas características podem cair em domínios extremamente complexos e até indecidíveis mas, mais uma vez, têm valor para que o domínio de uso da ontologia esteja explícito, tanto para nós como para outros. De entre as características relevantes que definimos que acabam por mais tarde ser garantidas por nós destacam-se as características das propriedades dos objetos (como: functional, inverse functional, transitive, symmetric, etc.) que explicitámos exaustivamente quando considerámos adequado. Assim, a nossa ontologia apresenta várias relações e características que facilitam a sua leitura e, ainda que muitas delas tenham que ser mantidas pela aplicação, é útil tê-las explicitadas na ontologia. ## Arquitetura de Alto Nível A nossa solução é constituída por 4 aplicações: 1. WSTV Repository Builder – Constrói o repositório (neste caso um ficheiro) 2. WSTV Ontology Builder – Constrói a triple-store com a ontologia com base no ficheiro criado pelo Repository Builder. 3. WSTV Index Builder – Constrói o índice utilizado na pesquisa sintática. 4. WSTV Web – O portal web. Utiliza a triple-store e o índice. O WSTV Repository Builder constrói o repositório com base em duas fontes de dados: http://www.imdb.com/ (através de screen-scraping) e http://imdbapi.com/ (através de uma API em JSON).  ## Componentes e Módulos da Aplicação Web Dada a utilização da framework Play, à partida a aplicação web ficou estruturada segundo o modelo MVC: + Views – Templates baseados em HTML utilizados para mostrar a informação que lhes é passada pelo Controller. + Controller – Neste caso só existe um Controller. Este é composto por várias ações, sendo que cada uma corresponde a uma View com o mesmo nome. + Models – É aqui que está toda a lógica de Web Semântica: representações em memória de séries, atores, personagens e criadores; queries SPARQL; acesso aos índices do Lucene; pós-processamento dos resultados das pesquisas; e algoritmo de recomendação. ### Lista das Views/Controllers + *index* - Home-page. Contém a listagem completa de séries, atores, criadores, géneros, anos e tags bem como algumas recomendações. + *name* - Apresenta todas as informações disponíveis sobre um ator ou criador. + *title* - Apresenta todas as informações disponíveis sobre uma série. + *char* - Apresenta todas as informações disponíveis sobre um personagem. + *find* - Apresenta os resultados de uma pesquisa. + *visual* - Página do Visual Navigator. ### Classes que fazem parte dos Models + *JSONAssembler* - Traduz um objeto Java para uma String JSON. Utilizado para converter listas de séries. + *Pair* - Classe genérica que representa um Par. Muito útil para implementar rankings. + *Person* - Representa uma pessoa que neste caso pode ser um ator, criador ou personagem. + *Recomendations* - Implementa o algoritmo de recomendação. + *SearchModel* - Classe base para as classes de procura. + *SearchResult* - Representa um resultado de uma pesquisa. + *SemanticSearch* - Implementa a pesquisa semântica. + *SemanticSearchUtils* - Implementa as funções que lidam diretamente com o motor SPARQL. + *Series* - Represente uma série de televisão. + *SyntaticSearch* - Implementa a pesquisa sintática. + *TripleStoreManager* - Gere a ligação à triple-store. + *TSModel* - Classe base para Models baseados em dados na triple-store. Classe mãe de Person e Series. + *Utils* - Contém funções utilitárias. ### Pesquisa Sintática A pesquisa sintática utiliza um índice construído pela ferramenta Lucene. O processo de construção é executado na aplicação WSTV Index Builder e é constituído pelas seguintes fases: 1. A página inicial (index) é adicionada à fila de páginas para analisar. 2. Se a fila estiver vazia termina. Se não passa a 3. 3. É tirada uma página da fila e é verificado se o seu url já foi analisado. Se não, passa a 4 se sim volta a 2. 4. Caso não tenha sido processada, a página é analisada tanto a nível de ocorrências de palavras como a nível de links existentes. Todos os urls dos links são adicionados à fila. Volta a 2. Há que notar que os links para pesquisas não são considerados e que links diferentes que apontem para o mesmo recurso são filtrados. Quando o utilizador insere uma query e escolhe o modo de pesquisa “Statistic” na aplicação web, a query é passada ao Lucene que devolve um conjunto de resultados ordenado pelo número de hits das keywords inseridas. Por uma questão de simplicidade apenas são exibidos no máximo 20 resultados. ### Pesquisa Semântica Nesta subsecção é descrita a implementação da procura semântica. #### i. Parsing de Queries Dado que não era objetivo deste trabalho utilizar técnicas elaboradas de Natural Language Processing (NLP) foram feitas algumas simplificações a nível do parsing de queries de procura semântica, nomeadamente: + As queries têm de seguir uma estrutura pré-definida (ver tabela). É de notar que existe um mecanismo de reserva caso a query não siga a estrutura. Nesse caso é assumida a estrutura #1, apresentada na tabela, que se baseia em assumir que todas as keywords da pesquisa são uma instância a pesquisar de uma qualquer classe. + Classes, predicados e separadores têm de ser obrigatoriamente representados por palavras singulares, isto é, uma classe não pode ser representada por “Series de TV”. Esta restrição de nomenclatura só se aplica às palavras utilizadas nas queries e não às outras componentes do projeto. ##### Estrutura válida das queries. Estar dentro de [] significa que podem ser colocadas várias instâncias separadas por "and". <table class="table"> <thead> <tr> <th>#</th> <th>Estrutura</th> <th>Objectivo</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>«valor»</td> <td>2.2</td> </tr> <tr> <td>2</td> <td>«classe» «valor»</td> <td>2.3</td> </tr> <tr> <td>3</td> <td>«classe» [«predicado» «valor»]</td> <td>2.4</td> </tr> <td>4</td> <td>«classe» [«predicado» from «valor» to «valor»]</td> <td>2.5</td> </tr> <td>5</td> <td>«classe» «valor» «classe 2»</td> <td>2.6</td> </tr> </tbody> </table> A nossa solução, apesar de restritiva, permite bastante flexibilidade. Destacam-se algumas características, por exemplo: + As procuras são case-insensitive. + São permitidos sinónimos (por exemplo TVSeries ? Series). + Permite escolher entre pesquisa em Inglês e Português. Esta funcionalidade só está parcialmente implementada já que era apenas uma prova de conceito. As propriedades que podem ser utilizadas em Português são título, da classe Series, e ano da mesma classe. A cada uma das estruturas na tabela corresponde uma função a que chamamos de primitiva. Cada uma destas funções recebe como parâmetros os campos referidos na tabela, com a ressalva de que quando existem intersecções estas são tratadas separadamente, ou seja, é feita uma chamada à primitiva por cada condição. Tal decisão foi tomada para simplificar a implementação e teste das primitivas e aumentar a modularidade e potencial de reutilização do código. A deteção da estrutura é feita com base em funções que, conforme a língua escolhida pelo utilizador, tentam encontrar correspondências entre as palavras na query e a forma correta (igual à que está na ontologia). Caso não exista nenhuma correspondência é devolvido null. Existem funções para traduzir classes, predicados e predicados numéricos (aos quais é possível aplicar um intervalo). Por outras palavras, para descobrir a estrutura das keywords usadas na pesquisa são utilizadas as funções para determinar se determinada keyword é classe ou propriedade, por exemplo. A função try2Resolve2Class(String w) tem o nome das classes e os sinónimos e tenta fazer a correspondência devolvendo o nome exato da classe (como apresentado na ontologia) ou null se não for feita correspondência. Por exemplo podemos chamar *try2Resolve2Class*(“Series”) e obtemos como return “TVSeries”. A função *try2Resolve2Prop*(String classWord, String propWord, String language) é um pouco mais elaborada (uma vez que existe um grande número de propriedades na ontologia, o que tornou necessário automatizar a tarefa de as percorrer). Com este objetivo é utilizada uma query para encontrar todas as subclasses da classWord que tenham determinada propriedade. Logo que seja encontrada uma um caso que satisfaça a condição é devolvida a propriedade (uma vez que na ontologia não existem duas propriedades diferentes com nomes iguais). Não foi implementado registo de utilizadores, login e recomendações semânticas baseadas em histórico guardado por utilizador (foi sim implementada recomendação semântica baseada em histórico guardado na sessão do browser), uma vez que tal não ia contribuir para a complexidade ou interesse da vertente semântica da nossa aplicação. A gestão de utilizadores neste contexto não está relacionada com web semântica e sugestões por histórico de conta seriam uma simples extensão de sugestões baseadas no histórico da sessão. #### ii. Primitivas Na estrutura #1 é assumido que as palavras de procura são um valor que pode corresponder à instância de qualquer classe cujos elementos tenham as suas próprias páginas, como tal realiza-se a procura comparando com todas as instâncias das classes Actor, Creator, Character e TVSeries, unindo-se todos os resultados de procura num conjunto. Por outras palavas, é chamada quatro vezes a função *find*(String className, String instance), sendo que className vai assumir os valores “Actor”, “TVSeries”, “Character” e “Creator” e instance vai ter as keywords usadas na pesquisa. Como exemplo se procurarmos a atriz Emma Bell, as queries SPARQL utilizadas seriam semelhantes à seguinte: ``` PREFIX foaf: <http://www.semanticweb.org/ontologies/2011/9/WSTV.owl#> PREFIX foaf2: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> SELECT ?s WHERE { ?s foaf2:type foaf:Actor . ?s foaf:hasName ?instanceName . FILTER regex(?instanceName, "Emma Bell", "i" ) } ``` A flag “i” torna as correspondências às expressões regulares case-insensitive. Para a estrutura #2 é novamente utilizada a função *find*(String className, String instance) e quando o className corresponde a Actor, Creator, Character ou TVSeries a query SPARQL utilizada é semelhante à anterior. Contudo, existem ainda casos especiais como para as classes Tag ou Genre. Para Genre por exemplo a query seria a seguinte: ``` PREFIX foaf: <http://www.semanticweb.org/ontologies/2011/9/WSTV.owl#> SELECT ?s WHERE { ?s foaf:hasGenre foaf:"+instance+"} ``` Na estrutura #3 é utilizada a função *findByProp*(String className, String propName, String propValue, String language). Nesta função mapeiam-se os parâmetros para className, que tem propriedade propName com o valor propValue. A query SPARQL utilizada é a seguinte: ``` PREFIX foaf: <http://www.semanticweb.org/ontologies/2011/9/WSTV.owl#> PREFIX foaf2: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX foaf3: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?s WHERE { { {?s foaf2:type foaf:"+className+"} UNION {?s foaf3:subClassOf foaf:"+className+"} } . ?s foaf:"+propName+" ?o . FILTER regex(?o, \""+propValue+"\", \"i\" )} ``` Se o parâmetro language fosse Português, o mapeamento com propName seria usado em relação à anotação em Português da propriedade. A query para este caso seria: ``` PREFIX foaf: <http://www.semanticweb.org/ontologies/2011/9/WSTV.owl#> PREFIX foaf2: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX foaf3: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?s WHERE { { {?s foaf2:type foaf:"+className+"} UNION {?s foaf3:subClassOf foaf:"+className+"} } . ?propo foaf3:comment \""+propName+"\"@pt . ?s ?propo ?o . FILTER regex(?o, \""+propValue+"\", \"i\" )} ``` Note-se que por defeito a aplicação lida com as queries em Inglês. Na estrutura #4 é utilizada a função *findByRange*(String className, String proposition, double start, double end). Por exemplo, se estivermos a fazer uma range query de séries entre dois anos, a query é a seguinte: ``` PREFIX foaf: <http://www.semanticweb.org/ontologies/2011/9/WSTV.owl#> PREFIX foaf2: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX foaf3: <http://www.w3.org/2000/01/rdf-schema#> SELECT ?s WHERE { { {?s foaf2:type foaf:"+className+"} UNION {?s foaf3:subClassOf foaf:"+className+"} } . ?s foaf:"+proposition+" ?year . FILTER (?year > "+start+") . FILTER (?year < "+end+")} ``` Como se pode observar é possível utilizar os filtros do SPARQL diretamente (de forma semelhante ao SQL) para restringir valores numéricos. Na estrutura #5 vai-se encontrar a instância (ou instâncias) da primeira classe e de seguida devolver as instâncias da segunda classe relacionadas com a primeira instância. Exemplos de procura seriam: + “Series south Actor” que irá encontrar instâncias “south” da classe TVSeries e de seguida devolver instâncias de Actor relacionadas com essa instância. Por outras palavras, os resultados seriam links para as páginas dos atores da série south park. + “Actor Summer Glau Series” vai encontrar todas as séries em que a atriz Summer Glau tenha participado. A função utilizada é *find*(String className, String instance, String assocClassName). Esta função começa por chamar a função *find*(String className, String instance) com os dois primeiros parâmetros (className e instance). Um exemplo desta query para o segundo caso seria: ``` <http://www.semanticweb.org/ontologies/2011/9/WSTV.owl#> PREFIX foaf2: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> SELECT ?s WHERE { ?s foaf2:type foaf:Actor . ?s foaf:hasName ?instanceName . FILTER regex(?instanceName, "Summer Glau", "i" ) } ``` De seguida vão-se buscar todas as propriedades possíveis para unir a instância à segunda classe. Tomando novamente como exemplo a segunda pesquisa semântica as propriedades possíveis entre a instância “Summer Glau” da classe Actor e TVSeries são as Object Properties *hasPerformedInTVSeries* e *isStartOf*. Tendo esta informação vão-se buscar as instâncias que estão relacionadas com a Actor Summer Glau (com identificador único nm1132359) através destas propriedades. Um exemplo desta query é apresentado de seguida: ``` PREFIX foaf: <http://www.semanticweb.org/ontologies/2011/9/WSTV.owl#> SELECT ?o WHERE { { foaf:nm1132359 foaf:hasPerformedInTVSeries ?o } UNION { foaf:nm1132359 foaf:isStarOf ?o } } ``` ### Algoritmo de Recomendações As recomendações feitas ao utilizador têm como base o seu histórico de visualização de páginas de séries durante a sessão. A visualização de atores, criadores e personagens não tem qualquer influência na recomendação. Uma das razões desta decisão é que essa informação já pode ser consultada na secção de filmografia, ao aceder à página da pessoa. Contudo, a razão principal para não fazermos sugestões com base em eixos, como por exemplo ator, é que temos uma base de dados de séries relativamente pequena na qual é raro um ator ter participado em mais do que uma série. Quando o utilizador não tem histórico são recomendadas séries que fazem parte de um conjunto de séries de alta qualidade e/ou interessantes definido na ontologia. O propósito é que é preferível recomendar séries de qualidade do que não recomendar nenhuma ou usar um critério aleatório. Além disso, de todas as N séries neste conjunto só são recomendadas no máximo 4, escolhidas aleatoriamente e não ordenadas (para evitar que se sugiram sempre as mesmas). Com base no histórico do utilizador são construídos dois histogramas, um de géneros e outro de criadores. Estes histogramas vão contar todas as ocorrências de um determinado género ou criador. É de notar que não foram descartadas séries que aparecem no histórico mais que uma vez – se essas séries foram mais visitadas os seus atributos devem ter mais relevância. Com base nos dois histogramas é calculada a pontuação de todas as séries no dataset. Esta pontuação (ou P) é calculada da seguinte forma: 1. Inicia P a 1. 2. Para todos os géneros, adiciona a P o valor desse género no histograma. 3. Para todos os criadores, adiciona a P o valor desse criador no histograma. 4. Multiplica P pelo rating da série dividido por 10. O objetivo do passo 4 é, sobretudo, evitar que séries de muito baixa qualidade sejam recomendadas. P é iniciado a 1 para que, caso existam poucas correspondências com géneros ou criadores, as restantes séries sejam ordenadas pelo seu rating. Por fim, as séries são ordenadas por P e são recomendadas as 5 melhor classificadas de acordo com este sistema. De notar que séries no histórico não são recomendadas (porque o utilizador já as viu), nem a série que o utilizador possa estar a ver no momento. ### Visual Navigator O Visual Navigator é um hibrido entre navegação e recomendação. A ideia base é ver, num plano 2D, o quão próximo estão todas as séries no dataset de uma série alvo. Quanto maior essa proximidade menos distantes do centro aparecerão as séries. Para tornar a visualização mais interessante cada série é representada pela sua imagem sendo que o tamanho desta também reflete (de forma equivalente à distância ao centro) a afinidade com a série alvo (maior - mais próxima). A proximidade é baseada numa pontuação – a mesma utilizada para as recomendações. O algoritmo e o código são os mesmos, a única diferença é que neste caso a única série no “histórico” é a série alvo (de notar que a utilização desta feature não altera de forma nenhuma a funcionalidade de recomendação). Também é possível filtrar as séries visíveis por ano e rating. Esta funcionalidade é exemplo das vantagens da modularidade da aplicação web. Em termos de back-end, implementar esta feature limitou-se à utilização da componente de pesquisa semântica por intervalo. Além das referidas existe ainda mais uma série de funcionalidades para enriquecer a experiência do utilizador: + On mouse over mostra uma tooltip com o título, ano, rating e géneros da série. Também faz zoom à imagem e coloca-a à frente de outras que eventualmente se estiverem a sobrepor. + Ao clicar na série alvo é aberta a sua página num novo separador. + Clicar numa série que não a alvo faz com que essa se torne o alvo.  <hr/> <div class="alert alert-warning"> <a target="_blank" href="http://student.dei.uc.pt/~catre/" >Pedro Gil Catré</a> & <a target="_blank" href="http://student.dei.uc.pt/~lfac/">Luís Filipe Cardoso</a>. Web site criado com http://strapdownjs.com/ <p>Copyright © 2012</p> </div>