Agenda-setting: Devaluation of the Arctic Council?

A World Wide Web, ou simplesmente Web, tem alterado radicalmente o modo de como compartilhamos conhecimento, diminuindo as barreiras entre fornecedores e consumidores de informação.

Apesar dos grandes benefícios já providos em termos de interligação de do- cumentos, o mesmo não se pode dizer com relação aos dados. A Web atual é con- siderada uma Web voltada mais para os documentos do que para os dados. Nestes documentos (páginas Web) os dados estão disponíveis (inseridos em tabelas, ou em formatos XML) de uma forma desestruturada e sem uma semântica. Não fossem os

cérebros humanos especializados na seleção e integração da informação, de pouco adiantaria a Web da forma como se apresenta até algum tempo atrás.

Recentemente, a Web tem agrupado documentos onde também os dados po- dem ser relacionados/conectados. O termo Linked Open Data ou simplesmente Lin- ked Data (LD) refere-se a este conjunto de boas práticas para publicar e estabelecer ligações entre estes datasets (conjuntos de dados) abertos visando acrescentar no espaço Web uma espécie de banco de dados de nível global (ou Linked Open Data Cloud). Assim, LD nada mais é do que criar conexões entre dados de fontes diferen- tes. Este conjunto de boas práticas foi explanado em uma nota redigida por Tim Berners-Lee41 e se resume nos seguintes passos:

1. Use URIs (Uniform Resource Identifiers) para nomear tudo (use URIs para pessoas, frutas, carros etc. Mas também para conceitos abstratos como amor, guerra, estatísticas etc.)

2. Use HTTP URIs de modo que seja possível encontrar estes nomes na Web (Sempre que houver um pedido HTTP get, alguma coisa deve ser retornada, nesse caso RDF.)

3. Quando alguém acessar um URI, forneça informação RDF útil.

4. Inclua links para a outros URIs de modo que seja possível descobrir mais coi- sas (Esses links são propriedades RDF, e.g. foaf:knows, dc:subject).

A idéia básica dos LD é aplicar os padrões de arquitetura já estabelecidos pe- la World Wide Web42 para executar a tarefa de compartilhamento dos dados estrutu- rados em uma escala global43_.

Uma vez que os dados foram nomeados e disponibilizados, de acordo com os princípios descritos acima (passos 1 e 2), os mesmos podem ser acessados por ou- tras aplicações. Estas formas de acesso se dão por intermédio da exploração das várias propriedades da arquitetura dos LD.

Atualmente existem vários datasets relacionados com o domínio da música conforme mostra a Figuras 8. A intenção é relacionar estes dados com aqueles tipi- camente de uma BD, no contexto da catalogação bibliográfica.

41 _{Disponível em http://www.w3.org/DesignIssues/LinkedData.html. Acesso em 30/10/2011.} 42 _{Disponível em http://www.w3.org/TR/Webarch/. Acesso em 30/10/2011.}

43 _{Atualmente, a nuvem LD conta com aproximadamente 4,5 bilhões de triplas e 180 milhões de links} de dados.Fonte: linkeddata.org

Figura 8: Nuvem Linked Data composta por 203 datasets, com detalhe da nuvem Linked Data onde, na cor azul claro, é mostrado a área de conhecimento destinada à música

Seguindo esta mesma tendência de disponibilizar informações para que ou- tros usuários e sites da Web as utilizem, estão aqueles serviços denominados de API Web, tais como os providos pela API Amazon Product Advertising44 _{e pela API}

Flickr45. O site ProgrammableWeb46 mantém uma relação de milhares dessas APIS disponíveis para serem utilizadas por terceiros.

As API Web fornecem acesso simples para consulta a dados e o seu advento levou a uma explosão de pequenas aplicações especializadas (ou mashups) que combinam dados de várias fontes. Cada fonte acessa seu provedor de dados atra- vés de uma API específica. Diferente do padrão LD, as API, por utilizarem de um conjunto específico de comandos e de uma estrutura de dados, resultam numa difi- culdade extra para os desenvolvedores, pois estes devem compreender os métodos disponíveis para recuperar os dados de cada API, gerando códigos personalizados para acessar os dados de cada fonte diferente.

Desenvolver mashups tornou-se uma grande tendência (YEE, 2008), pois as numerosas fontes de dados disponíveis proporcionam a possibilidade de “remixar- mos”, ou seja, criarmos aplicações especializadas de acordo com a necessidade de públicos/nichos específicos, como preconizados por Anderson (2006), em sua teoria da Cauda Longa.

No domínio da música, destaca-se a plataforma The Echo Nest47, que dispo- nibiliza suas informações através de API Web. Ela é alimentada por algoritmos de aprendizagem de máquina (data mining), de processamento de linguagem natural e de análise acústica. O serviço agora oferecido está baseado em 12 anos de projetos de pesquisa e desenvolvimento conjuntos do Massachusetts Institute of Technology (MIT) e das Universidades de Columbia e Berkeley. The Echo Nest praticamente analisa todas as músicas na Web, extraindo características musicais tais como, tem- po, tonalidade, ritmo e timbre e outros atributos, na tentativa de descrever músicas da mesma forma que um músico o faria. Por exemplo, o sistema descreveria o ritmo samba como tendo "um andamento de 147 BPM e um compasso 4/4". Além disso The Echo Nest vasculha a Web na tentativa de analisar os post de blogs, cada co- mentário, cada pedaço de texto que por ventura descreva determinada música para

44 _{http://docs.amazonWebservices.com/AWSECommerceService/latest/DG/. Acesso em 30/10/2011.} 45 _{http://www.flickr.com/services/api/. Acesso em 30/10/2011.}

46 _{http://www.programmableWeb.com/. Acesso em 30/10/2011.} 47 _{http://the.echonest.com/. Acesso em 30/10/2011.}

sintetizar, em tempo real, o que as pessoas sabem ou estão comentando sobre de- terminada música ou artista.

Da mesma forma, o Facebook tornou disponível sua API48, o que permite o desenvolvimento de serviços de características sociais que se autodenomina Social Open Graph, o coração de toda a aplicação do Facebook. Através deste grafo estão conectadas pessoas, suas preferências pessoais ou ações sociais, fotos, lugares e etc.

No caso de uma BD, os benefícios da sua utilização estão desde a mescla dos dados já existentes com aqueles advindos da atividade social desses usuários até a integração dos sistemas de login e cadastro de usuários, possibilitando assim a qualquer Web site a implementação da sua própria comunidade ou rede social, além de utilizar, se antes não a dispunham, de uma camada de registros demográfi- cos sobre usuários, possibilitando a adoção de estratégias particulares de comparti- lhamento das informações e atingindo uma escala de visibilidade global.

Existem diversos tipos de integração admitidas quando se faz uso de APIs de mídias sociais. Por exemplo, no Facebook existem 3 níveis de integração entre essa plataforma com um Web site qualquer: (i) pela utilização de plugins sociais, que en- capsulam as social features utilizando umas poucas linhas de código; (ii) pela auten- ticação de usuários, simplificando e aumentando o número de novos usuários que utilizam as credenciais (login e senha) do Facebook; e (iii) pelo acréscimo e adequa- ção mais profunda dos serviços oferecidos pelo Web site frente a totalidade dos re- cursos providos pelo Facebook, através da utilização de todo o potencial da rede de usuários e todas as suas conexões (relacionamentos), para criar uma experiência ainda mais personalizada para os seus usuários.

Assim, utilizando este Open Graph, é possível construir, no âmbito de uma BDM, “ações sociais” (botões) entre os usuários e inerentes à música como, por e- xemplo: “estou ouvindo tais músicas”, “já toquei tal música”, “esta música é boa para casamentos”, que possibilitariam a troca e aquisição de informações de contexto úteis e que ajudariam a expandir o conceito atual de Objeto Informacional Musical, conforme necessidade que adiante será explicitada.

Portanto, a integração de BDM ou remixagem de dados com aquelas informa- ções advindas dos sites de redes sociais e de outras API musicais, pode ser vanta-

josa para uma BDM potencializando seu caráter social e oferecendo serviços perso- nalizados e menos institucionais.