With the transition of the Web of today from an information repository to a suite of services, the demand for machine-readable data to support the latter is now greater than ever. The social and, more generally, community element is proving to be a valuable medium to convey such a bulk of knowledge. Linked Data is a leading body of standards for publishing and using open knowledge bases on the Web, however, it very much relies upon the notion of identity. Every object of the world being described should be uniquely identified in order to be effectively manipulated. Music is a specially provocative domain of interest for such Web knowledge bases, being a topic where most people feel confident they can contribute to, yet with varying degrees of factual knowledge, personal inclination or scholarly rigour. Curating a dataset that covers an aspect new to this landscape, as is the evidence of listening experiences, means dealing with partial, inexplicit or underspecified information. A likely implication is that several elements of a listening experience, such as the listeners, the time in history or the music being heard, can be described to an extent but not identified, thus in stark contrast with a founding principle of Linked Data. This talk will illustrate the nature of the main elements of fuzzy knowledge that emerged from the contributions to the Listening Experience Database, elaborate on the countermeasures adopted and lessons learnt from the life-cycle of LED data, and assess the state of maturity of Linked Data technologies for accommodating such use-cases.

1. Linkage in Haze
Challenges and take-home messages of crowd-sourcing
vagueness in musical data
Alessandro Adamou
Listening to music: people, practices and experiences
Sunday, October 25, 2015

2. What we capture in a listening experience

3. what they said
where
documented where
who
what
when
how
What we capture in a listening experience

4. A well-formed listening experience
On July 19, 2014
Leonie Holmes (a professor of Music in New Zealand)*
was listening to Johann Strauss’ “Don Juan”
and “Also Spracht Zarathustra”
and Sarah Ballard’s “Synergos”
played by the NZSO National Youth Orchestra
and Alexander Shelley
using harp and double bass (+others?)
in the Aotea Centre.
(*) plus a generic public, which does not pose a problem in the representation.

5. A worst-case (but more likely)
listening experience
One evening between May and September
in the late 1950’s
a group of war veterans, a reporter and an
unknown female
were listening to Chopin and an anthem
played by a string orchestra
in a concert hall in South London.

6. Goal: to capture both fact sets
as structured data
(interconnected or prepared for
refinement)

7. Other issues
• Source
– unpublished manuscripts
• Unaligned semantic layers
– instrument category | instrument name | brand and model
– generic occupations | gender-dependent | personal titles
Monarch
King (Queen), Emperor (Empress)…
King of England, fourth Sultan of Zanzibar…
Chords
Electric Guitar
Gibson Les Paul Custom Sunburst

8. Factors contributing to fuzziness
• Domain knowledge of the evidence author(s)
• Deterioration of evidence
• Crowd-sourcing community issues:
– Misaligned semantics
– Varying scholarly rigour
– Popularity of the domain of interest

9. Data representation in LED
• Linked [Open] Data http://linkeddata.org
– Formalism for machine-readable and human-
readable data
– Object identifiers are URIs
– Standard representation and query languages
(RDF, SPARQL…)
– The meaning of links between objects is
globally understood.

10. Identity in Linked Data
• http://musicbrainz.org/artist/f5aca88c-e3c1-4bc2-af33-
68a9a9f7b56a#_
– (the band Killing Joke, as in MusicBrainz)
• http://bnb.data.bl.uk/id/agent/DailyMirror
– (The Daily Mirror on the British National Bibliography)
• http://dbpedia.org/resource/London
– (London, as in Wikipedia/DBpedia)
• http://reference.data.gov.uk/doc/day/2015-10-23
– (last Friday, as in the UK Government Calendar data)
• http://led.kmi.open.ac.uk/term/Medium.Live
– (the concept of live music, as in LED)

11. Identity in Linked Data
• http://musicbrainz.org/artist/f5aca88c-e3c1-4bc2-af33-
68a9a9f7b56a#_
– (the band Killing Joke, as in MusicBrainz)
• http://bnb.data.bl.uk/id/agent/DailyMirror
– (The Daily Mirror on the British National Bibliography)
• http://dbpedia.org/resource/London
– (London, as in Wikipedia/DBpedia)
• http://reference.data.gov.uk/doc/day/2015-10-23
– (last Friday, as in the UK Government Calendar data)
• http://led.kmi.open.ac.uk/term/Medium.Live
– (the concept of live music, as in LED)
Easy: these are all named entities…

12. Goal: to capture both fact sets
as linked data
There are no right or wrong
ways to do it, only linkable or
unlinkable.

13. Linked Data encourage reuse…
No two things are distinct nor equal, until
some LD node asserts or implies otherwise.
– e.g. Bono on MusicBrainz and Bono on DBpedia
– Groups too, if it can be demonstrated they are an
exact match

14. …but fuzzy concepts have caveats
Group entity “Mourners of Felix Mendelssohn” (attending
the arrival of his body in Berlin)
See http://led.kmi.open.ac.uk/entity/lexp/1434029100189
• Identifier of the group is
http://data.open.ac.uk/led/agent/Mourners+of+Felix+Mendelssohn/1434029100190
should not be reused when modelling an entry about
Mendelssohn’s funeral service.
See http://led.kmi.open.ac.uk/entity/lexp/1434029387526
– Identifier of the group is
http://data.open.ac.uk/led/person/Mourners+at+the+Funeral+Service+of+Felix+Mende
lssohn/1434029247629

15. Blank nodes
• Fallback mechanism for providing data about objects
without having a naming convention for them.
• Reference something not by name, but by description.
• Example:
:performance/Messiah/12345 mo:listener [
a foaf:Group ;
dc:description “Foreign ambassadors”
:occupation dbpedia:Ambassador
]
• Generally not an advisable solution:
– Cannot perform matching on blank nodes
– Querying or detecting changes in the data is much harder

16. Ontological classes
• Model vague objects as formally-specified categories rather than named
entities
• e.g. “the class of all people whose occupation is Ambassador and who were
at the Royal Albert Hall on May 12, 1876”
• Pros:
– Allows separation of “known” and “generic” entities
– Semantically cleaner and easier to store and manage
• Cons:
– Still need to make URIs for each class
– They have to be instantiated before they can be used in a listening
experience
– Harder to apply changes to the data without fixed classes

17. Countermeasures in LED
• No blank nodes
• For unaligned semantic layers (cf.
example on instruments and
occupations):
–Use lax model properties
–Enforce reuse of external taxonomies
• ‘rich’ real-time recommendations

18. Countermeasures in LED
Data reconciliation
Currently with restricted
access, but plans to open
to crowd-sourcing

19. Countermeasures in LED
• Ad-hoc formal models for underspecified data.
• Example: Extended Date/Time Format (standard draft, Library of
Congress, 2012)
– Allows formalisation of underspecified points in time and intervals, e.g.
“187u-05-uu”
– We extended it to support subjective fuzzy intervals (e.g. early/mid/late)
and ranges (from-to)
– Made available in RDF through data.open.ac.uk
• Example 2: GeoSPARQL
– Used to support geospatial queries in Linked Data
– Named entity recognition on arbitrary text for locations (recently)
– We compute location URIs by hashing their descriptions and all the
locations extracted from it and related via geosparql:sfIntersects

20. How thick is the mist in LED?
Named Vague Total
Participants 802 260 1062
Locations 136 15
(cannot pinpoint)
151*
Times 826 843
(ranges, not qualified)
1669
Musical works 1550 1263 2813
(*) since database opened to arbitrary experience locations
Figures for LED public dataset

21. Lessons learnt
• Advantages
– Open-world semantics: minimise risk of ambiguities
generated by name clashes, allows for coherent management
– Monotonic: data are refined by addition of facts
– Can be reasoned upon by machine-learning agents working
on the native data structure
– Incorporates reuse for the benefit of the whole data cloud.
• Disadvantages
– No reuse entails heavy replication
– Data cleansing may require a large context for detecting entities
that can be reconciled

22. Lessons learnt
• Most, if not all representational issues with vagueness can be
addressed in LD without resorting to blank nodes and safe from
ambiguity.
– Way more powerful that traditional database systems.
• Data providers are yet to reach an albeit silent agreement on:
– representational paradigms for entities commonly at risk of
underspecification, such as spatio-temporal ones;
– how to name their objects.
• Most are making it easy for themselves when it comes to LD
• The way to go is de facto standards

23. Where to go next
• Model ontological classes as their instances
(equivalence classes?)
• Increase context for fact-based data alignment
(opening reconciliation facilities to the public –
with voting?)
• Argumentation on every statement in LED
• Dissemination of controlled vocabularies and
naming convention for managed vague entities.

24. Are Linked Data mature for
representing vagueness?
• The technology is.
• The data out there aren’t.
– (but that is the part that can be improved)

25. Further reading
• Eero Hyvönen, Publishing and Using Cultural Heritage Linked
Data on the Semantic Web (Morgan & Claypool, 2012)
• Daniel J. Lewis and Trevor P. Martin, Managing Vagueness with
Fuzzy in Hierarchical Big Data. In 2015 INNS Conference on Big
Data (Elsevier, 2015), Procedia Computer Science, Vol. 53, p. 19-28
• Fuzzy Logic and the Semantic Web, Elie Sanchez (ed.) (Elsevier,
2006)

26. Thank you!
QA time
alessandro.adamou@open.ac.uk