L. POTOMS J DELVA
11) C Const., n° 115/2018 du 20 septembre
3.1 ABORDAGEM ADOTADA
A estratégia concebida e utilizada para responder a questão da pesquisa a- presentada anteriormente é experimental, pois várias variáveis independentes foram manipuladas (causa) para analisar as consequências desta manipulação sobre uma ou mais variáveis dependentes (efeitos), dentro de uma situação controlada.
Por outro lado, Feitelson (2006) questiona se os componentes que tradicio- nalmente definem a ciência experimental (observação, teste de hipóteses e reprodu- tibilidade) realmente se aplicam à Ciência da Computação Experimental (CCE). A CCE é tratada como uma disciplina que envolve a criação e/ou experimentação e análise de artefatos computacionais e se difere das demais ciências (Física, Quími- ca, etc.) pelo fato da relação entre teoria e experimentação não ser necessariamente intensa. Esses autores advogam que o trabalho experimental deve complementar a pesquisa teórica, pois, argumentam, na Ciência da Computação, nem toda pesquisa pode ser resolvida teoricamente. Desta forma, a CCE está intimamente relacionada à criação de artefatos computacionais, que podem ser definidos como a implemen- tação de um ou mais fenômenos computacionais que podem ser extraordinariamen- te complexos.
Entre os artefatos na pesquisa em CCE se encontra a “prova de conceito”. De acordo com Almeida (2010) um artefato desse tipo:
[...] demonstra, pelo seu comportamento, que um sistema complexo de componentes pode executar um determinado conjunto de atividades. O comportamento deste artefato não poderia ser inferido ou determinado a partir de uma argumentação lógica ou uma argumentação baseada em al- guns princípios básicos. Assim, o sistema em operação, isto é, o artefato, é uma “testemunha” de prova que os conceitos estão corretos, pelo menos para aquela configuração.
Assim, compõem a metodologia utilizada no presente trabalho, além da pes- quisa bibliográfica, a construção de um experimento no qual foi construído um arte- fato (prova de conceito) com o intuito de demonstrar como trazer a BDM para o atual ecossistema da informação e comunicação e adequar o modelo FRBR às necessi- dades de informações musicais dos seus usuários.
3.2 PROPOSTA INICIAL
A construção do artefato computacional foi norteada pelo conceito de organi- zação do conhecimento, conforme defendido por Morin (2003), que se constitui num processo simultâneo de tradução e de reconstrução, de separação e união. Ainda segundo Morin (2003), “como nosso modo de conhecimento desune os objetos entre si, precisamos conceber o que os une”.
Partindo dessa premissa, a idéia, para a consecução do objetivo declarado, é conceber um modelo de dados que acolha os registros musicais no formato FRBR e os relacione com informações de diferentes outros dois domínios: (i) dos usuários, via API de uma rede social e (ii) de provedores de informações musicais, tais como o Linked Data e do The Echo Nest. Utilizando um banco de dados baseados em gra- fos, tal estratégia procura promover a primazia das relações dos objetos informacio- nais musicais em detrimento das suas propriedades e atributos bibliográficos e, ao mesmo tempo, preserva a compatibilidade com o padrão proposto pela IFLA (1998). Propõe-se também a instanciação desse modelo por meio da realização de uma prova de conceito.
Por abrigar dados de diferentes domínios e de características semi- estruturadas, além do foco aqui serem os relacionamentos em detrimentos dos obje- tos em si, optou-se por utilizar um modelo de dados orientado a grafos.
Para efeito da operacionalização da prova de conceito, serão utilizados regis- tros no formato FRBR oriundos da BDM Variations87, desenvolvida pela Universida- de de Indiana, providos no formato XML88 e modelados na forma de grafos, confor- me exemplo mostrado na Figura 18.
A esse processo de importação dos dados no formato FRBR para um modelo baseado em grafos, foi dado o nome de “ferbergrafização”, uma alusão ao termo “ferberização”, usado pela comunidade de informação para o processo de migração de dados provenientes de sistemas legados para o modelo FRBR.
87 http://variations2.indiana.edu/. Acesso em 30/10/2011.
Figura 18: Exemplo de representação em grafos para um modelo FRBR
Uma vez “ferbergrafizados”, estes dados bibliográficos são relacionados com aqueles oriundos: (i) das API de sites de redes sociais, ou seja, com os usuários dessas redes sociais e sua rede de amigos, conforme sugere Cruz (2008) ao refe- renciar a expansão do objeto informacional musical, e, conforme sugere Coyle (2010) para retirar as BD do isolamento informacional, (ii) do Linked Data, relativos aos autores das obras musicais, e (iii) do The Echo Nest, em relação às obras e ex- pressões. O foco nos relacionamentos – uma das principais vantagens do modelo de grafos – permite, com uma maior naturalidade, a adição dessas outras “camadas” de dados, já que pode ser feita com a utilização de operações de menor custo compu- tacional. O esquema apresentado na Figura 19 contempla, por um lado, as caracte- rísticas do atual ecossistema da informação e comunicação, representadas na figura pela camada (a), que contém um grafo com os dados bibliográficos (FRBR), acresci- do da camada (b) de usuários, com as informações advindas da utilização de API dos sites de redes sociais (c). O resultado é uma BDM que atua como um dos nós das redes sociais. Além disso, os dados bibliográficos são conectados ao conjunto de dados disponibilizados pelos projetos Linked Data e The Echo Nest (d), resultan- do na expansão dos domínios tradicionais de uma BDM. O modelo contempla ainda a definição estendida de Objeto Informacional Musical, pela consideração dos rela- cionamentos (e) entre as camadas (a) e (b), que representam a correlação usuário- música resultante das atividades sociais dos usuários no âmbito dos atuais sites de redes sociais (por exemplo, a funcionalidade do botão “curtir” disponível no Facebook).
Figura 19: Estrutura de dados representada em camadas
Para o desenvolvimento da prova de conceito foram observadas as premis- sas: (i) execução em navegadores Web (inclusive naqueles disponíveis em apare- lhos celulares que, conforme apresentado no referencial teórico trata-se de uma ten- dência e característica do atual ecossistema da informação e comunicação); (ii) utili- zação de ferramentas, elementos e componentes que contemplem licenças no âmbi- to do conceito de software livre89 e (iii) acesso somente de usuários cadastrados em uma rede social. A rede social escolhida foi o Facebook.
Os componentes utilizados foram os seguintes:
(i) A plataforma de desenvolvimento Java. Trata-se de uma plataforma, versátil, eficiente e já suficientemente testada e refinada por uma comunidade de com mais de 6,5 milhões de desenvolvedores, é a tecnologia mais ampla e ativa do planeta90. Permite também, como é o presente caso, criar programas para exe-
cução em navegadores e serviços da Web;
(ii) A linguagem jRuby91, versão da linguagem Ruby, totalmente integrada ao Java que permite a incorporação do interpretador em qualquer aplicação Java com acesso bidirecional completo entre o Java e o código Ruby;
(iii) O banco de dados Neo4j92, baseado em grafos (NoSQL);
(iv) O utilitário de indexação Apache Lucene93, uma biblioteca94 que implementa um motor de busca textual de alta performance, escrito inteiramente em Java. É
89 Todo e qualquer programa de computador cuja licença de direito de autor conceda ao utilizados as seguintes 4 liberdades de: (i) executar o programa, para qualquer propósito; (ii) estudar como o pro- grama funciona, e adaptá-lo para as suas necessidades; (iii) redistribuir cópias de modo que você possa ajudar ao seu próximo; e (iv) aperfeiçoar o programa, e liberar os seus aperfeiçoamentos, de
modo que toda a comunidade se beneficie. (fonte:
http://pt.wikipedia.org/wiki/Licen%C3%A7a_de_software_livre. Acesso em 30/10/2011.) 90 http://java.com. Acesso em 30/10/2011.
91 http://www.jruby.org. Acesso em 30/10/2011. 92 http://www.neo4j.org. Acesso em 30/10/2011.
uma tecnologia adequada para qualquer aplicação que requer pesquisa de tex- to completo;
(v) A biblioteca Ruby FBGraph95 para acesso a API do Facebook;
(vi) A biblioteca Sinatra96 de aplicativos Web utilizada para responder as requisi- ções Web de aplicações escritas em Ruby;
(vii) Rest-client97, biblioteca utilizada para acessar o serviço de recuperação de re- cursos (URI) da DBpedia (Linked Data)
(viii) TheJit98 (JavaScript Infovis Tollkit), API baseada nos padrões da Web para criação de visualização de dados de forma iterativa;
(ix) JQuery99, uma biblioteca que auxilia no desenvolvimento rápido de código ja- vascript que viabiliza, numa página Web, ações como a atribuição e manipula- ção de eventos (como por exemplo um click de um mouse) e a definição de e- feitos, como alterar ou criar elementos na página Web.
(x) O ambiente integrado para desenvolvimento de software Aptana Studio 3100; O hardware utilizado foi um notebook equipado com processador core Intel Duo, HD de 250 Gb com sistema operacional Windows 7, com acesso à Internet.
A metodologia de desenvolvimento do protótipo consiste de 3 etapas (Figura 20): (i) construção de um parse101 para importar e indexar dados contidos em arqui- vos XML, disponibilizados pelo projeto Variations, para um banco de dados transa- cional que armazena em uma estrutura baseada em grafos; (ii) revisão, e proposta de novos relacionamentos frente às API do Linked Data e The Echo Nest para se juntar àqueles já constantes nos arquivos XML/FRBR e (iii) construção de uma inter- face para o protótipo que apresente para o usuário resultados que incluam a expan- são dos relacionamentos e do OIM, antes representados pelas entidades e relacio- namentos contidos no FRBR original, com incorporação das API das redes sociais, do Linked Data e do The Echo Nest.
93 http://lucene.apache.org/java/docs/index.html. Acesso em 30/10/2011.
94 o termo biblioteca se refere a uma coleção de programas escritos em Java. 95 http://github.com/nov/fb_graph. Acesso em 30/10/2011. 96 http://www.sinatrarb.com. Acesso em 30/10/2011. 97 https://github.com/archiloque/rest-client. Acesso em 30/10/2011. 98 http://thejit.org/. Acesso em 30/10/2011. 99 http://jquery.com/. Acesso em 30/10/2011. 100 http://www.aptana.com/. Acesso em 30/10/2011
101 Parsing é o processo de analisar uma sequência de entrada, no caso: arquivos no formato XML, para, a partir de sua estrutura transformá-lo, em uma estrutura de dados, baseado em um banco de grafos, tornando-a assim conveniente para processamento posterior.
Figura 20: Etapas para desenvolvimento do protótipo
3.3 DELIMITAÇÃO DO ESTUDO
Não se pretendeu, neste projeto, investir em aspectos relacionados à forma- ção de coleções, definição de metadados, mecanismos de interoperabilidade, políti- cas de preservação digital, e questões de direito autoral sobre coleção musical dis- ponível em Bibliotecas Digitais Musicais. Questões relativas a usabilidade, desen- volvimento de interfaces, ou de mecanismos de recuperação da informação musical também não fazem parte do escopo deste trabalho. Dentre os diversos modelos que recomendam regras para a catalogação bibliográfica, esta pesquisa se ateve ao mo- delo FRBR pelo fato deste ser preconizado pela principal instituição internacional representativa do universo das bibliotecas e dos profissionais da informação, além de ser amplamente considerado no âmbito das BDM (AYRES, 2004; ASSUNÇÃO, 2005; DIET e KURTH, 2007; RILEY, 2008).
4
RESULTADOS ALCANÇADOS4.1 ETAPAS DE DESENVOLVIMENTO
A seguir, são detalhadas as etapas de desenvolvimento da prova de conceito (Figura 19).
Passo 1 - Construção de um parse para importar e indexar dados contidos em ar-
quivos XML, disponibilizados pelo projeto Variations, para um banco de dados transacional que armazena em uma estrutura baseada em grafos Como já mencionado, a BDM Variations da Universidade de Indiana realizou uma série de testes com dados baseados no modelo FRBR. Para que desenvolve- dores pudessem também produzir seus próprios testes com dados reais de produ- ção, esta instituição disponibilizou uma vasta documentação que inclui um conjunto de dados “ferberizados”102 para download, no formato de arquivos XML.
Para este fim, a equipe do projeto denominado V/FRBR tem desenvolvido um conjunto de esquemas XML que se espera evoluir para uma melhor prática para a representação de dados bibliográficos FRBRizados em XML.
O pacote completo dos esquemas de V/FRBR é composto de 132 documen- tos W3C Schema XML divididos em três "níveis". Este conjunto de esquemas V/XML FRBR estão disponíveis em duas formas: (i) Como um conjunto de arquivos posta- dos em um servidor publicamente acessível, no http://vfrbr.info/schemas/ ; (ii) como um conjunto de arquivos envolvido em um pacote para download, em http://vfrbr.info/schemas/schemas.zip.
Os esquemas XML apesar de terem sido projetados para o projeto Variations oferecem um modelo replicável para outros catálogos FRBRizados. Dentre as princi- pais razões do projeto Variations para a elaboração de tais esquemas XML estão: (i) Fornecer um modelo reutilizável para representação de dados em XML em confor- midade com o modelo FRBR para a implementação de outros sistemas FRBR; (ii) representar em um formato XML (a) as entidades do Grupo I do FRBR e seus atribu- tos; (b) as entidades do grupo 2 do FRBR e seus atributos e (c) os relacionamentos definidos no relatório FRBR; e (iii) permitir, no todo ou em parte, a reutilização das entidades do FRBR e seus atributos e relacionamentos por outros aplicativos.
No escopo deste trabalho os esquemas XML foram utilizados somente como fonte de dados para povoar/instanciar em banco de grafos as entidades, seus atribu- tos e relacionamentos que estão representadas no modelo FRBR. Não serão feitas referências diretas aos arquivos musicais (MP3 ou em outros formatos).
Apesar dos arquivos XML estarem estruturados em 3 níveis aqui considera- mos apenas o nível mais simples que é o FRBR e que representa as entidades, atri- butos e relacionamentos descritos neste modelo, desconsiderando portanto os ní- veis “eFRBR” (abreviação de "frbr estendido") e “vfrbr" (abreviação de "Variati- ons/FRBR”) que se destina à representação de dados específicos do projeto V/FRBR.
Conforme se verifica no Quadro 4, o nível de esquemas XML FRBR simples- mente define elementos XML para cada entidade FRBR e subelementos para cada atributo FRBR. Os elementos XML são nomeados de acordo com o informado no relatório FRBR103, com os espaços entre as palavras removidos. Todos os atributos FRBR são definidos como elementos XML com um tipo de dados string.
Existe um elemento <entities> para cada nível do FRBR que possui um atributo identifier que é o identificador para cada elemento XML que representa uma entidade FRBR. Esse acréscimo permite que sejam recriados os relacionamentos entre as entidades.
Cada um dos esquemas do nível de entidades define algumas extensões para os atributos FRBR que adiciona um elemento <note>, bem como um elemento <ex- tensions> que se destina a permitir adições locais ao namespace do modelo FRBR.
Quadro 4: Esquema XML para entidades FRBR
<efrbr:entities>
<efrbr-person:person identifier="http://vfrbr.info/person/71345"> <efrbr-person:nameOfPerson type="authorized" vocabulary="naf"> Carp, David M
</efrbr-person:nameOfPerson>
<efrbr-person:nameOfPerson type="variant"> Carp, David (David M.)
</efrbr-person:nameOfPerson>
<efrbr-person:note avail="public">
OCLC, 9/9/97 (hdg.: Carp, David M.; Carp, David; usage: David M. Carp; David Carp)
</efrbr-person:note>
<efrbr-person:note avail="public">
Taylor, D. David Taylor, bass trombone [SR] 1996: container (David Carp, ka- zoo, recorder) </efrbr-person:note> </efrbr:entities> 103 http://www.ifla.org/publications/functional-requirements-for-bibliographic-records. Acesso em 30/10/2011.
No elemento <relationships> (vide quadro 5) para cada nível, a estrutura de empacotamento XML é dividido em segmentos para as estruturas das relações es- trutura, relações responsáveis, relações assunto, e outras relações. O agrupamento destas divisões é baseado no relatório original FRBR e descreve as relações FRBR.
Dentro do elemento <relationships> para cada nível, a estrutura de empaco- tamento XML é dividido em segmentos “structureRelations”, “responsibleRelations” e “subjectRelations”. Estas divisões são baseadas na forma de como o relatório do FRBR descreve as relações.
Estruturas de relações (structureRelations) são aquelas entre as entidades do Grupo 1: obra (work), expressão (expression), manifestação (manifestation) e item (item). Cada obra é realizada através de um conjunto de expressões, expressões estão incorporadas em manifestações e manifestações são exemplificada por itens. Relações de responsabilidade (responsibleRelations) ocorrem entre o Grupo 2 e as entidades do Grupo 1. Obras são criados por entidades do Grupo 2, expressões são realizados por entidades do Grupo 2 e manifestações são produzidos por entidades do Grupo 2. Finalmente, relações de assunto (subjectRelations) acontecem entre obras e qualquer entidade do Grupo 1 ou 2 que servem como um assunto (subject) de determinada obra.
Todas as relações em todas as categorias estão representadas nestes forma- tos XML em uma direção única, tendo uma relação específica atributos de origem e de destino onde os identificadores são fornecidos.
Quadro 5: Esquema XML para relacionamentos FRBR
<efrbr:relationships> <efrbr:structureRelations> <efrbr:realizedThrough source=http://vfrbr.info/work/1 target="http://vfrbr.info/expression/1"/> </efrbr:structureRelations> <efrbr:responsibleRelations> <efrbr:producedBy source=http://vfrbr.info/manifestation/2 target="http://vfrbr.info/person/5"/> <efrbr:producedBy source=http://vfrbr.info/manifestation/2 target="http://vfrbr.info/corporateBody/6"/> <efrbr:realizedBy source=http://vfrbr.info/expression/5 target="http://vfrbr.info/person/7"/> </efrbr:responsibleRelations> </efrbr:structureRelations> <efrbr:relationships>
A partir desta estrutura dos arquivos XML foi concebida uma rotina de impor- tação desses dados com a finalidade de persisti-los, devidamente indexados104, no
banco de grafos Neo4J.
Passo 2 - Revisão, e proposta de novos relacionamentos frente às API do Linked Data e The Echo Nest para se juntar àqueles já constantes nos arquivos XML/FRBR
Para a consecução desta etapa foram elaborados apenas 2 casos de uso a saber: (i) usuário entra (faz o login) no aplicativo e (ii) usuário faz pesquisa por pala- vra chave e navega por entre os resultados dessa pesquisa. Em ambos os casos de uso somente serão considerados o fluxo principal de eventos.
O primeiro caso de uso descreve o processo pelo qual os usuários entram no aplicativo da BDM. Para obterem sucesso, os usuários deverão ter uma conta no Facebook. Seu fluxo principal é o seguinte:
1. O caso de uso começa quando o usuário inicia a aplicação 2. A aplicação solicita a autenticação delegada junto ao Facebook
3. A API do Facebook retorna o token do usuário autenticado. Este token é utili- zado para acessar os serviços do Facebook relacionado a aquele usuário (fa- zer post, enviar email, obter informações sobre a relação de amigos etc.)
4. O sistema estabelece permissões de acesso e mostra as informações referen- tes a sua rede de amigos que utilizam a BDM
5. Enquanto o usuário não encerra a aplicação (loop)
6. Ele pode fazer uma pesquisa textual nos registros da BDM
7. Ele pode clicar no nome dos amigos e obter informações sobre objetos musi- cais com os quais este amigo se relacionou
8. O caso de uso termina
O segundo caso de uso descreve o processo pelo qual os usuários fazem uma pesquisa textual e navegam por entre os resultados dessa pesquisa. Para obte- rem sucesso, os usuários deverão estar “logados” na aplicação. Seu fluxo principal é o seguinte:
1. O caso de uso começa depois do usuário obter sucesso no login 2. Usuário clica na caixa de texto “Pesquisar” e inicia a digitação do texto
3. A medida que vai digitando, o aplicativo mostra uma lista de palavras/termos
104 A indexação se faz necessária para implementação da funcionalidade de busca pelos registros. dada um palavra-chave, conforme wireframe apresentado na Figura 20.
que se encontram na base de dados (sugest)
4. A pesquisa é iniciada quando o usuário clica em uma das palavras contidas na lista de palavras sugeridas
5. O resultado da busca é mostrado na forma de um grafo (nós e arestas) 6. Enquanto o usuário não encerra a aplicação ou não faz outra pesquisa (loop) 7. O usuário pode clicar em determinado nó e:
a. o aplicativo mostra as propriedades daquele nó e mostra os possíveis rela- cionamentos (na forma de links) daquele nó com conteúdos disponíveis do Linked Data ou The Echo Nest. Se o usuário clicar num desses links uma nova janela se abrirá e o respectivo conteúdo será mostrado.
b. Clicar no botão “gostei” a aplicação irá publicar uma atualização do “status” no mural do Facebook do usuário e uma mensagem será mostrada indican- do o êxito da operação.
8. Fim do Loop;
9. O caso de uso termina.
Passo 3 - Construção de uma interface para o protótipo que apresente para o usuá-
rio resultados que incluam a expansão dos relacionamentos e do OIM com a incorporação das API das redes sociais, do Linked Data e do The Echo Nest.
Para a interface do sistema produzido, foi desenhado um único e simples wi- reframe105 (Figura 21), com 3 colunas. A coluna da direita concentra as informações de login do usuário e aquelas relacionadas às suas conexões sociais. A coluna cen-