We present the Listening Experience Database (LED), a structured knowledge base of accounts of listening to music in documented sources. LED aggregates scholarly and crowdsourced contributions and is heavily focused on data reuse. To that end, both the storage system and the governance model are natively implemented as Linked Data. Reuse of data from datasets such as the BNB and DBpedia is integrated with the data lifecycle since the entry phase, and several content management functionalities are implemented using semantic technologies. Imported data are enhanced through curation and specialisation with degrees of granularity not provided by the original datasets

Adamou, Alessandro

Barlow, Helen

Brown, Simon

d'Aquin, Mathieu

English

Open Research Online (The Open University)

Open Research OnlineThe Open University’s repository of research publicationsand other research outputsLED: curated and crowdsourced linked data on musiclistening experiencesConference or Workshop ItemHow to cite:Adamou, Alessandro; d’Aquin, Mathieu; Barlow, Helen and Brown, Simon (2014). LED: curated and crowdsourcedlinked data on music listening experiences. In: Proceedings of the ISWC 2014 Posters & Demonstrations Track, CEURWorkshop Proceedings, CEUR-WS.org, pp. 93–96.For guidance on citations see FAQs.c© 2014 The AuthorsVersion: Version of RecordLink(s) to article on publisher’s website:http://ceur-ws.org/Vol-1272/paper 74.pdfCopyright and Moral Rights for the articles on this site are retained by the individual authors and/or other copyrightowners. For more information on Open Research Online’s data policy on reuse of materials please consult the policiespage.oro.open.ac.ukLED: curated and crowdsourced Linked Data onMusic Listening ExperiencesAlessandro Adamou1, Mathieu d’Aquin1, Helen Barlow1 and Simon Brown21 The Open University, United Kingdom{alessandro.adamou, mathieu.daquin, helen.barlow}@open.ac.uk2 Royal College of Music, United Kingdomsimon.brown@rcm.ac.ukAbstract. We present the Listening Experience Database (LED), astructured knowledge base of accounts of listening to music in docu-mented sources. LED aggregates scholarly and crowdsourced contribu-tions and is heavily focused on data reuse. To that end, both the storagesystem and the governance model are natively implemented as LinkedData. Reuse of data from datasets such as the BNB and DBpedia is inte-grated with the data lifecycle since the entry phase, and several contentmanagement functionalities are implemented using semantic technolo-gies. Imported data are enhanced through curation and specialisationwith degrees of granularity not provided by the original datasets.Keywords: Linked Data, Crowdsourcing, Digital Humanities, Data Workflow1 IntroductionMost research on listening to music focuses on investigating associated cognitiveprocesses or analysing its reception by critics or commercial indicators such assales. There is only sporadic research on the cultural and aesthetic position ofmusic among individuals and societies over the course of history. One obstacleto this kind of research is the sparsity of primary source evidence of listening tomusic. Should such evidence be compiled, we argue that the adoption of explicitstructured semantics would help highlight the interactions of listeners with arange of musical repertoires, as well as the settings where music is performed.With the Listening Experience Database (LED)1, we aim at coveringthis ground. LED is the product of a Digital Humanities project focused ongathering documented evidence of listening to music across history and musicalgenres. It accepts contributions from research groups in humanities as well asthe crowdsourcing community, however, the data management workflow is super-vised to guarantee that minimum scholarly conventions are met. Being conceivedwith data reuse in mind, LED is natively implemented as Linked Data. All theoperations in the data governance model manipulate triples within, and across,named RDF graphs that encode provenance schemes for users of the system.1 LED, online at http://www.open.ac.uk/Arts/LEDSeveral content management functionalities available in LED, such as contentauthoring, review, reconciliation and faceted search, incorporate Linked Datareuse. Reused datasets include DBpedia2 and the British National Bibliography(BNB)3, with music-specific datasets currently under investigation. Reused dataare also enhanced, as the LED datamodel is fine-grained and allows for describingportions of documents and excerpts, which are not modelled in the datasets athand. LED therefore also aims at being a node by its own right in the LinkedData Cloud, providing unique content and contributing to existing data too.At the time of writing, the LED dataset stores about 1,000 listening experiencerecords contributed by 25 users, half of whom being volunteers from the crowd.2 Related workA similar effort in aggregating structured data in primary evidence was alreadycarried out for reading experiences [1], though the process was not data-drivenand the resulting Linked Data were only marginally aligned. We also acknowl-edge a project being carried out, which gathers direct personal experiences ofyoung users of the system, albeit with a minimal data structure4. We also drewinspiration from earlier accounts of using DBpedia for music, such as the dbrecrecommender [3]. Crowdsourcing is also gaining the attention of the SemanticWeb community, with very recent attempts at tackling data quality aspects [4].3 The Listening Experience DatabaseWe define a listening experience (LE) as a documented (i.e. with a quotableand citable source) engagement of an individual in an event where some pieceof music is played. In terms of conceptual modelling, a LE is a subjective event,and one document describing it is the quoted evidence reported in the database.The lifecycle of data in LED involves the roles of contributor, consumer andgatekeeper, and states called draft, submitted, public and blacklisted. Every arti-fact stored in the system exists in one or more of these states (except blacklistedones, which exclude all other states), and a state determines if a user with acertain role can “see” an artifact or not. What these artifacts are, depends onthe specific phases in the workflow, which are transitions between these states.Authoring. Contributors populate the knowledge base by entering data ona LE and its associated entities. The entry forms are dynamic and provide sug-gestions and autocompletion data from LED and external datasets in real time(cf. Figure 1). Artifacts declared during this phase remain in a draft state, onlyto enter a submitted state once the contributor submits the LE to gatekeepers.Review. Privileged users with the gatekeeper role review a submitted artifactand either promote it to the public state, or reject it for blacklisting, or demote it2 DBpedia, http://dbpedia.org3 British National Bibliography, http://bnb.data.bl.uk4 Experiencing Music, http://experiencingmusic.comto draft again, which they can do by either taking over the artifact and amendingits data themselves, or sending it back to the original contributor.Reconciliation. Gatekeepers can align and merge duplicate artifacts thatare found to match. They can compare candidate duplicates with other artifactsin LED and third-party data. This operation does not modify their state.Faceted search. Consumers can navigate LE’s by filtering keyword searchresults by bespoke criteria which are not necessarily stored in LED, but alsoreused from third-party datasets. Only public artifacts contibute to searches.(a) Listening experience submission. (b) Autocompletion from the BNB dataset.Fig. 1: Example of data entry for “Pictures from Italy” by Charles Dickens.With a native Linked Data implementation, we can immediately integratereuse with every stage of the data lifecycle starting with data entry, and eliminatea posteriori revision and extraction phases from the workflow, thereby reducingthe time-to-publish of our data and having them linked right from the beginning.Also, the named graph model of quad-stores can encode provenance informationwith the granularity of atomic statements [2], thus lending itself to fine-grainedand complex trust management models.To encode the above workflow entirely in RDF, we used the named graphparadigm in order to represent states and artifacts. Deciding on the scale ofthe latter was an issue: while we intended to give gatekeepers control on singleRDF triples (or quads, from the named graph perspective), and to contributorsa way to support the truth or falsehood of a triple, this can be complex andtime-consuming. Therefore, artifacts are encapsulated into LE’s, musical works,literary sources, agents (e.g. people, groups or organisations) and places: theseare, for instance, the classes of artifacts that gatekeepers may want to review orreconcile. However, LE’s remain the core artifacts of the sytem: only by creatingor editing them can their associated artifacts be generated.The LED knowledge base is partitioned into data spaces, each belongingto a user or role. Every contributor owns two RDF graphs, one for draft ar-tifacts and one for submitted ones. Thus, we can keep track of which con-tributors support a fact by reusing it (e.g. <Messiah (oratorio) composerGeorg Frideric Handel>). There is a single graph for public artifacts, and onefor blacklisted ones. Contributors have access to the graphs they own plus thepublic graph; gatekeepers can access every user’s submitted graph and the pub-lic and blacklist graphs. State transitions are realised by parametric SPARQLqueries that selectively move RDF triples across these graphs. Along with thesedata spaces there are rules that determine the visibility of triples to each user,depending on the content of their private graphs. In general, these rules assumecontributors have greater confidence in the facts in their possession, and whenmissing, they should trust those provided by the community or other datasets.4 DemonstrationThe audience will be given a live demonstration of the LED system, but fromthe point of view of users with the privileged roles of contributor and gatekeeper.We will show the benefits of reusing data from indexed datasets during the entryphase, as well as the implementation of our governance model in Linked Dataand its effects on the representation of a resource as seen by the general publicor a specific user. Data reuse and enhancement will be demonstrated through aLE entry form to be auto-populated in real time and open to input by audiencemembers. To demonstrate the governance model, we will run two distinct entrieswith shared data through the whole draft-submission-gatekeeping lifecycle. Wewill then show how differently the shared data and their RDF representationsappear to each user, based on the trust and provenance policies in place.References1. Matthew Bradley. The Reading Experience Database. Journal of Victorian Culture,15(1):151–153, 2010.2. Jeremy J. Carroll, Christian Bizer, Patrick J. Hayes, and Patrick Stickler. Namedgraphs, provenance and trust. In Allan Ellis and Tatsuya Hagino, editors, WWW,pages 613–622. ACM, 2005.3. Alexandre Passant. dbrec - music recommendations using DBpedia. In Peter F.Patel-Schneider, Yue Pan, Pascal Hitzler, Peter Mika, Lei Zhang, Jeff Z. Pan, IanHorrocks, and Birte Glimm, editors, International Semantic Web Conference (2),volume 6497 of Lecture Notes in Computer Science, pages 209–224. Springer, 2010.4. Elena Simperl, Maribel Acosta, and Barry Norton. A semantically enabled architec-ture for crowdsourced linked data management. In Ricardo A. Baeza-Yates, StefanoCeri, Piero Fraternali, and Fausto Giunchiglia, editors, CrowdSearch, volume 842 ofCEUR Workshop Proceedings, pages 9–14. CEUR-WS.org, 2012.

LED: curated and crowdsourced linked data on music listening experiences

http://oro.open.ac.uk/42045/1/paper_74.pdf

LED: curated and crowdsourced linked data on music listening experiences

Abstract

Similar works

Full text

Available Versions

Open Research Online (The Open University)