Kapittel 4 – Metodologiske tilnærminger
4.3 Forskningsprosessen
Com vista a se poder obter resultados mais confiáveis, que visem obter conhecimento real acerca das preferências musicais de cada utilizador, foi necessário obterem-se dados que representassem a realidade histórica das preferências exercidas por ouvintes em contextos conhecidos. Deste modo é importante salientar que se perspetivou não apenas recolher informação relativa à lista de músicas que um dado utilizador ouviu num período de tempo passado mas, também, a todos os fatores que possam ter influenciado a audição musical em determinado momento. Isto é, tal como foi explicado na introdução dos objetivos do presente trabalho, procurar-se-á obter padrões que traduzam conhecimento que permita avaliar se existem dimensões que influenciam diretamente as características das músicas que ouvimos. Desta forma, os conjuntos de informação que se obtiveram para fazer estes relacionamentos constituem:
- dados meteorológicos - relativos ao estado do tempo aquando a audição de determinada música;
- dados temporais - relativos ao dia do ano, dia da semana ou minuto do dia aquando foi feita a audição;
- dados caracterizadores do utilizador - género, nacionalidade ou idade do ouvinte. Tais conjuntos constituem na sua globalidade o conjunto de dados base sobre os quais este caso de estudo irá incidir.
4.1.1
Processo de obtenção de dados reais
O objetivo primordial assente no estudo discutido e desenvolvido no presente projeto prima pela construção de uma aplicação final que procure maximizar a satisfação do utilizador aquando do uso da mesma. Para este objetivo ser concretizado torna-se necessário que seja reproduzida a música apropriada, à hora apropriada, no local apropriado. É neste contexto que surge a necessidade em serem recolhidos todos os dados de interesse que possam condicionar os gostos musicais do utilizador. Se pensarmos um pouco sobre as músicas que estamos a ouvir e a razão pela qual escolhemos aquela música em detrimento de outra, em dado momento, apercebemo-nos que um dos fatores que tem maior peso nas nossas decisões advém do nosso estado emocional. É claro que qualquer pessoa diria que escolheu ouvir aquela música porque gosta daquele género musical, daquele artista, daquela banda ou ainda daquele álbum. Contudo, além desta nossa
primeira pré-seleção surge logo uma outra a seguir que irá, por vezes de forma irrefletida, traduzir o nosso estado emocional. Ora, todo este prelúdio explicativo dos fatores que condicionam as nossas escolhas musicais, abre portas para, agora sim, para serem abordados com mais rigor os fatores que serão obtidos e que serão cuidadosamente analisados no processo de extração de padrões e que se possam traduzir em conhecimento.
Deste modo, por forma a poderem-se obter dados reais acerca das preferências históricas de ouvintes inseridos em contextos conhecidos, foi feito uso do webservice disponibilizado pela aplicação Last.fm3. Neste ponto será, então, importante definir com algum detalhe esta fonte de
dados. Do mesmo modo que no site da empresa é apresentado, a aplicação Last.fm caracteriza-se por ser um serviço de descoberta de músicas que prima por fazer recomendações com base nas músicas que o utilizador ouve. Além disso, assume-se ainda como sendo o maior catálogo musical online do mundo, alimentado pelos seus “scrobbles”. O nome “scrobbles” advém do facto de alguns dados históricos sugerirem que o projeto inicial e originário do Last.fm, foi o Audioscrobbler4. Iniciado em 2002 e criado por Richard Jones, o Audioscrobbler tinha como
objetivo principal a gravação histórica das músicas que os utilizadores ouviam e, a partir desta, construía os dados de recomendação através de tabelas colaborativas. Com o passar do tempo e com a fusão com o “Last.fm” o projeto alargou-se, sendo no momento um Web rádio com sistemas de recomendação orientados ao utilizador.
Como será de fácil percepção, esta aplicação não difere em muito do objetivo do presente projeto, contudo será importante notar que, durante o processo de recolha de informação, não foram recolhidos nenhuns dados relativos à recomendação calculada para cada utilizador nem, ainda, quaisquer dados sobre os quais a política de privacidade aceite pelo utilizador da aplicação “Last.fm” não referisse como sendo disponíveis ao público. A recolha de informação foi então feita graças a uma API pública disponibilizada por esta aplicação que permite que se faça uso do seu webservice para o efeito. Os métodos disponibilizados pela API poderão ser visualizados em www.last.fm/api e permitem, entre outros, obter a lista das últimas músicas ouvidas pelo utilizador, obter informação sobre cada música, artista e/ou álbum, obter a lista de tags que caracterizam cada um dos elementos atrás enumerados (música, artista e/ou álbum), obter dados estatísticos que permitam saber qual o número de reproduções, número de ouvintes, número de
3 http://www.last.fm/
tags atribuídas e qual o uso das mesmas. Além disso, permite ainda obter dados pessoais referentes a cada utilizador. Deste grande conjunto de informação disponível procurou-se estruturar os dados pretendidos numa base de dados relacional e, desta forma, foi desenvolvida uma pequena aplicação em c# que permitiu a obtenção e povoamento da base de dados descrita. Para além desta recolha de informação relativa ao historial de preferências musicais de cada utilizador, foi ainda necessária a definição de algumas formas que permitissem satisfazer o conhecimento necessário das dimensões que envolviam cada audição musical. Foi neste contexto que surgiu o auxílio da GHCN5 como base para obtenção de informação histórica referente aos
dados meteorológicos em todo o mundo. Esta poderosa base de dados expõe dados como a temperatura, a precipitação e a pressão do ar, dados estes provenientes a partir de aproximadamente 6000 estações medidoras de temperatura, 7500 estações medidoras da precipitação e 2000 estações medidoras de pressão atmosférica. Os dados referidos estão disponibilizados de forma pública através de ficheiros individuais referentes a um ano em específico e, os mesmos, encontram-se estruturados sob o formato CSV. Tais dados foram lidos e extraídos com auxílio de um pequeno script desenvolvido em python6 e que permitiu o seu
armazenamento numa base de dados mysql7 - esta base de dados será usada numa fase posterior.
Neste ponto torna-se imperativo referir que toda a informação vem agrupada por estações meteorológicas e que a cada estação corresponderá a um país em específico. Um dos problemas com esta correspondência, e que será abordado com maior detalhe no subcapítulo referente à inconsistência dos dados, advém do facto de um país poder ter várias estações meteorológicas distribuídas não uniformemente por toda a área geográfica do mesmo e, desta forma, para um mesmo país poderão existir observações meteorológicas muito discrepantes.
Por fim surgiu uma última necessidade inerente à especificidade do estudo, a imprescindibilidade de se caracterizar de forma detalhada e alargada as músicas ouvidas pelo utilizador. Tais características resultantes constituem desta forma os fatos que se tentarão prever a partir das circunstâncias envolventes durante a audição de uma dada música. Posto este objetivo, essencial na resolução do domínio do problema, procedeu-se então à recolha de informação técnica a partir de uma biblioteca de dados fornecida pela empresa “The Echonest”8. O conjunto destes dados
5 www.ncdc.noaa.gov 6 http://www.python.org 7 http://www.mysql.com/ 8 http://echonest.com/
constituiu informação detalhada relativa a cerca de 1 milhão de músicas, das quais se podem visualizar informações relacionais, como o artista, álbum e tags/termos correspondentes do mesmo e, ainda, informações caracterizadoras, como a duração da música, o seu tempo (BPM), o seu grau de “danceabilidade” (estimação proveniente de um algoritmo usado), o modo, a key, o nível de energia da música do ponto de vista do utilizador, entre muitos outros. A lista de atributos caracterizadores de cada música selecionados para constituírem a base de estudo deste projeto, bem como os dados relacionais intrínsecos a cada uma delas, poderão ser consultados na tabela abaixo representada.
Característica Tipo de
Dados Descrição
Nome String Título descritor da música.
Danceabilidade Float Nível que representa a probabilidade relativa da música ser adequada para se dançar. Energia Float Nível de energia que a música transmite a partir do ponto de vista do ouvinte.
Key Integer Refere-se ao tom ou ao acorde característico da música.
Modo Integer Atributo com apenas dois valores possíveis: 0 e 1; correspondendo, respetivamente, a major e minor;
Loudness Float É respetivo à percepção que o ouvinte tem da potência dos sons constituintes da música.
Tempo Float Corresponde à “velocidade” da música. Muito conhecido por BPM-per Minute. Beats
Número de Beats Integer Número de batidas que a música tem.
Número de Secções Integer Número de secções que a música tem.
Duração Integer Duração da música.
Hottness Float Valor que surge como resultado de um algoritmo que procura calcular a popularidade. Respetivo ao artista, música ou álbum.
Ano Integer Ano de lançamento da peça musical.
Nome e MBID de
Artista String Nome e identificador do artista associado à música.
Termos do Artista ArrayStrings de Lista de termos descritores do artista. Inclui ainda frequência e peso de cada um deles.
Familiaridade do
Artista Float Nível de familiaridade apresentado pelo artista. Nome do Álbum String Nome do álbum a que a música pertence.
Tabela 4.1 Lista de atributos caracterizadores selecionados para constituírem as propriedades base das músicas do presente projeto.
O conjunto de dados obtidos a partir de um simples download disponibilizado na página “http://www.infochimps.com/collections/million-songs” encontra-se representado numa base de dados com, aproximadamente, 300Gb de informação. Os dados encontram-se estruturados num formato hierárquico desenhado pela NCSA, o HDF5. Sem entrar em grandes detalhes, o formato HDF, no caso HDF5, é um modelo de dados especialmente desenhado para que operações de I/O ocorrem de forma muito eficiente, rápida e de modo flexível. Este tipo de estrutura prima por organizar grandes volumes de dados em vários ficheiros localizados em diretórios que exprimam, no seu conjunto, algum tipo de significado para pesquisas efetuáveis. Pretende-se, desta forma, organizar a informação hierarquicamente num formato de diretórios do tipo árvore para, assim, diminuir o tempo de processamento em operações de pesquisa de informação. Pelo exposto e por forma a também se poder obter o máximo de performance no presente caso de estudo, foi utilizado o conjunto de dados descrito e foi construída uma pequena aplicação em python que permitisse o acesso aos dados a partir de aplicações externas, neste caso, aplicações desenvolvidas em c#, como será abordado nos subcapítulos seguintes.