Keywords

1 Introduction

Musical heritage encompasses a diversity of human expressions and experiences leaving heterogeneous traces that are difficult to describe, connect, and preserve [30]. In Europe, music cultural heritage developed through varied sources: musical contents and objects (such as tunes, scores, melodies, notations, recordings, etc.) linked to tangible objects (theatres, conservatoires, churches, instruments, etc.) but also to their cultural and historical contexts, opinions and stories told by people with diverse social and artistic roles (scholars, writers, students, intellectuals, musicians, politicians, journalists, etc.), and facts expressed in different styles and perspectives (memoire, reportage, news, biographies, reviews) in different languages (English, Italian, French, Spanish, and German) and across centuries [10]. This diversity creates unique opportunities as well as challenges for researchers and practitioners attempting to study and preserve music heritage.

In the H2020 Polifonia projectFootnote 1, various memory institutions, museums, music archives, scholars, commercial organisations, and citizens ask questions (e.g. “Which tunes share melodic patterns and geographical origin?”; “How do libretto and music relate, e.g. in describing an emotion?”; “Can we trace the evolution of tonality and transition from modal to tonal?”) across these multi-perspective and multi-modal sources. This demands the integration of musicological (notes, chords, modes, theories), historical (events, persons, places, objects) and archival/preservation (metadata, descriptors) data and perspectives. The project comprises 4 cultural institutions (CNAM, NISV, MiC, KNAW) and 10 pilots with a large variety and number of requirements. Ontologies and knowledge graphs (KGs) have the potential to overcome these challenges, and shed light on this wealth of resources by extracting, materialising and linking new music history knowledge that was previously overlooked and therefore missing [11, 46].

Various ontologies and knowledge engineering methods have been proposed and applied to music industry and cultural heritage [13, 48]. For example, Music Ontology [48] and DOREMUS [2] provide models to describe music metadata with a focus on discographic and classical music, respectively. Although these ontologies cover some aspects of musical heritage interest, they are individually insufficient to overcome the challenge of integrating the notation, metadata, and historical contexts needed for multi-perspective cultural analyses; thus leaving questions about the relationship between musical theory (melodies, tonalities, chords) and culture (historical events, architecture, geography) unanswered. To date, no available ontological framework integrates music metadata, notation, annotation, source provenance, and cultural heritage object descriptions. To the best of our knowledge, no toolkits exist to support knowledge engineering tasks around the lifecycle of competency questions, which is a central project requirement given the large number of variety of stakeholders, pilots and questions.

In this work, we describe the Polifonia Ontology Network (PON), a set of new ontologies formalising the semantics of music representation, metadata, annotation, analysis, mediums of performance (instruments), and historical sources (provenance), enabling the creation of interoperable knowledge graphs from music datasets. To achieve this, we apply and extend eXtreme Design (XD) [9], a well-known ontology design methodology where ontological requirements are gathered from a comprehensive inventory of competency questions (CQs), and modularity is fostered through the reuse of Ontology Design Patterns (ODPs) [24, 32]. We also release the PolifoniaCQ dataset, a collection of 361 competency questions on musical heritage. Further, we validate PON and provide evidence of its current and planned (re)use by three different types of users: (i) the Polifonia pilots, using them to generate musical culture KGs; (ii) a number of industrial and institutional stakeholders and early adopters, planning to use PON to annotate their in-house datasets; and (iii) a survey run in the Semantic Web and Music Technology communities showing intentions of use. More specifically, the contributions of this article are:

  • Extensions to XD centred around CQ extraction and enhancement, including both methodological (a CQ-elicitation framework to mirror use cases from domain experts) and technological (a toolkit for assisted design and iterative improvement of CQs through language models) aspects (Sect. 3).

  • PolifoniaCQ, a new dataset of competency questions driving the design and the evaluation of PON, with associated stories and personas (Sect. 3.1).

  • The Polifonia Ontology Network (PON v1.0) resources, available on GitHubFootnote 2 and including 15 (CC-BY 4.0) ontology modules (Sect. 4).

  • Evidence of reuse and impact from music stakeholders, applications within Polifonia, and interest from various research communities (Sect. 5).

2 Related Work

Ontologies play a fundamental role in the representation and management of knowledge, by providing common vocabularies to describe resources and queries. In the cultural heritage domain, there have been several efforts in this direction, such as the ArCo ontology, which pertains to the Italian cultural heritage [13], as well as others [11, 34]. Several ontologies exist in the music domain for addressing diverse applications, dealing with both symbolic notations and audio signal at different levels of specificity. MusoW [1] is a catalogue indexing online music resources, including ontologies and KGs. Here, we focus on music ontologies and categorise them according to their reference domain: (i) metadata; (ii) music theory; (iii) music notation; and (iv) audio features.

Multiple ontologies describe high-level music-related metadata, with the Music Ontology [48] and DOREMUS [41] being the most renowned. Other models focus on specific metadata: the OMAC Ontology describes musical works and claims about them [53]; the Performed Music OntologyFootnote 3 specialises on performances, and the OnVIE Ontology [55] describes mediums of performances. Similarly, the Musical Instrument Taxonomies [39] model instruments conceptually and terminologically, and the Smart Music Instrument Ontology [58] covers sensors and instruments within the realm of the Internet of Musical Things [57].

Some ontologies describe different elements ascribable to music theory. The Music Theory Ontology (MTO) [49] covers theoretical concepts of music theory, while the Functional Harmony Ontology [37] analyses harmonic sequences through reasoning. The Chord Ontology, Tonality Ontology, and Temperament Ontology [22] cover chords, tonal content, and instrument tuning, respectively.

Ontologies have also attempted to describe musical notation. For instance, the MIDI Linked Data Cloud [45] proposes a way to connect symbolic music descriptions that are encoded in the MIDI format. Meanwhile, the CHARM ontology [29] is focused on representing musical structures. The Music Theory Ontology (MTO) [49] aims to capture the theoretical concepts related to music compositions, while the Music Score Ontology (Music OWL) [36] and the Music Annotation Ontology [17] represent the content of a music score.

Other works focus on audio signals or the procedures used to produce them. For example, The Audio Features Ontology [3], The Studio Ontology [21], and The Audio Effects Ontology [59] are dedicated to describing different aspects of audio production. The Computational Analysis of the Live Music Archive (CALMA) [4] project aims to link metadata of music tracks with computational analyses of recordings, through feature extraction, clustering, and classification. Additionally, ontologies have been used to model listeners’ habits and music tastes, as well as similarities between different musical pieces [35, 38, 51, 56].

Despite the numerous contributions, the scope of these ontologies is often too specific or ingrained in a genre, style, historical period – often addressing individual music stakeholders and/or datasets. Several ontologies were also developed independently, with little coordination across relevant contributions. In turn, this often hampers reuse and extension, while jeopardising interoperability – an essential requirement for the integration of music datasets [12].

3 The eXtreme Design Methodology in Polifonia

The Polifonia Ontology Network (PON) addresses the aforementioned challenges by integrating heterogeneous requirements related to musical content and contexts into a modular yet unified architecture. To develop PON, we rely on, and extend, the eXtreme Design [8, 9] (XD) ontology engineering methodology. XD fosters the reuse of ontology design patterns (ODPs) [24, 32] and provides support to incrementally address small sets of requirements formalised as competency questions (CQs). This minimises the impact of changes in future releases, which is beneficial to Polifonia (heterogeneous project requirements and participants). Moreover, XD has been successfully applied to the cultural heritage domain [14], and our ontology designers have relevant experience in using this methodology.

The application of XD iterates over a series of steps, for which we detail their process while highlighting our main extensions (see Fig. 1).

3.1 Requirements Collection

Ontological requirements are collected from customers in the form of user stories (e.g. “Tosca was performed in Rome on 14 January 2000”), which are then translated as competency questions (CQs) – the natural language counterpart of structured queries that the resulting KG should answer [26]. For instance, the previous story may become “Where was a musical piece performed?”.

We borrow techniques from User eXperience design [25] to extend this framework with 3 new sections in the story template: persona, goal, and scenario. The persona is a research-based description of a typical user: name, age, occupation, skills and interests. The goal is a short textual description of what the persona aims to achieve in the story, complemented by a list of keywords (maximum 5) provided by the customers. The scenario describes how the persona’s goals are currently solved, to contextualise the gap with the resource being developed.

In cooperation with the domain experts in Polifonia (music historians, librarians, computational musicologists, music analysts, archivists, data engineers, etc.), 22 personas have been createdFootnote 4 from this step.

Fig. 1.
figure 1

Summary of the main Polifonia extensions to the eXtreme Design methodology.

Full size image

Iterative Refinement of CQs. Competency questions were then analysed to identify any inconsistencies that could create obstacles for ontology design. Common inconsistencies were due to vague concepts, for instance, the assertion of two compositions being connected without any specific context (in terms of the property) on which the connection can be established (e.g. similar melodies, rhythm). Other CQs were found to be overly complex or nested – entailing more than a single requirement as a result of nested logical operators articulating the question (e.g. “How is track B connected to C to conclude D?”). Such CQs needed to be conceptually simplified before being processed further.

To efficiently address these inconsistencies, we developed the Infer, DEsign, CreAte (IDEA) framework: analytical tools for CQ-driven ontology design based on language modelsFootnote 5. IDEA automatically extrapolates and organises CQs from a source repository, analyses them to find inconsistencies and similarities, and visually projects them to a sentence-level embedding space [54]. The framework has enabled the iterative refinement and improvement of CQs through human-machine collaboration: questions are first extracted and preliminary validated by tagging them (complex, nested, ill-formed, passing), then brought to the attention of the corresponding ontology designer whenever their intervention is needed. To date, 3 cycles of CQ improvement have been completed with IDEA. Instead, the analysis of CQ embeddings through similarity facilitated the identification of overlapping requirements from the pilots (beyond the syntactic level); which in turn enabled and fuelled discussion from various experts and pilots during our ontology design meetings (e.g. 2 CQs may have similar interpretation or semantics for OD, but entail different semantics across pilots).

The PolifoniaCQ Dataset. At the end of this process, we obtained 361 CQs, which are systematically collected in the PolifoniaCQ dataset with pointers to their personas and stories. We make this dataset available under CC-BY 4.0Footnote 6.

Fig. 2.
figure 2

Visualisation of the Polifonia CQ embeddings using TensorBoard.

Full size image

3.2 Ontology Network Design and Development

Clustering CQs as Ontology Modules. The refined CQs could then be translated in clear, atomic and consistent ontological requirements. Given the wide diversity of CQs – ranging from general events to musicological interpretations of specific passages in compositions, the first step was to achieve a meaningful categorisation into thematic clusters. This step led to the definition of the ontology modules shaping the architecture of the Polifonia Ontology Network.

To streamline this process, we analysed the CQ embedding space generated and projected by IDEA. This is done by computing the sentence-level embeddings (a feature vector of fixed size) for each CQ in the PolifoniaCQ dataset. The latter can be considered as a point in a high dimensional space – providing a numerical summary of the question’s meaning [18]. Embeddings are computed via Sentence-BERT [50] due to its state of the art performance on a number of question-related tasks, including multi-lingual search and paraphrase detection.

An interactive visualisation of the PolifoniaCQ embeddings is available from a live Tensorboard Projector [54] which is set up and synchronised via IDEAFootnote 7. The qualitative analysis of the embedding space, in addition to density-based clustering analysis under various parametrisations, have jointly facilitated the identification of common requirements (as nested clusters) and enabled the interactive exploration of the PolifoniaCQ dataset via similarity (c.f. Fig. 2).

Matching CQs to ODPs. For each module/ontology, an XD iteration starts from selecting a coherent set of CQs. To address those requirements, existing solutions (ODPs) from ontologies or online catalogues of patterns are considered for reuse, extension, and specialisation. For instance, a CQ such as “Where and when a situation took place?” can be matched to the TimeIndexedSituationFootnote 8 ODP, which represents temporal situations.

Here, IDEA supports the identification of “the CQ set” via the multi-lingual search feature. For example, an ontology designer looking for CQs related to places may express a search query as shown below in Listing 1.1.

figure a

Direct/Indirect Ontology Reuse. Depending on the project’s requirements, reuse of ontologies and ODPs is direct and/or indirect [15]. The former approach directly includes/imports ontologies or part of them (e.g. individual entities, relations) thus introducing a dependency to any possible changes and availability. In indirect reuse, relevant entities and patterns from other ontologies are used as templates (replicated and extended) while being aligned to ensure interoperability. In Polifonia, we follow a hybrid approach: ArCo ontology [13] is directly reused since its development and maintenance involves one of the project’s partners (MiC), while others (such as DOREMUS) are indirectly reused and aligned.

Validation and Testing. Ontology modules have been developed in close collaboration with domain experts and pilot leaders throughout the whole development cycle. This has allowed the ontology design team to leverage the domain expertise in Polifonia to technically validate our modules at different stages: from the collection and analysis of requirements, to iterations of ontology designs. Validation was facilitated by IDEA (at the CQ-level), and, at the modelling level, by the Graphical Framework For OWL Ontologies (Graffoo) notation [20] – providing a powerful visual language for coproduction activities. This has also been achieved through data snippets provided by the pilots, which have been modelled by our ontologies and triggered further iterations of improvements.

Overall, the involvement of domain experts from different institutions and background (complementary views and notions), the 10 pilots in the Polifonia project (reasonable diversity of application domains), and the use of collaborative workflows have also contributed to mitigate bias in the development of PON.

Fig. 3.
figure 3

Overview of the main modules in the Polifonia Ontology Network, with Polifonia’s pilots as early adopters (grey circles). Foundational models (Source, Instrument, Music Meta, Music Representation) provide the backbone of PON, built on top of the Core module while leveraging the main ontologies reused directly or indirectly.

Full size image

4 The Polifonia Ontology Network

The Polifonia Ontology Network (PON) provides a modular backbone of music ontologies to address both cultural heritage and more general queries in the music domain. As illustrated in Fig. 3, PON v1.0 comprises 15 ontology modules that are organised thematically (colours, horizontal view) and hierarchically, to highlight their dependencies (vertical view). At the bottom of the architecture lies our Core module (providing general-purpose elements of design, ODPs, and alignments) and the reused ontologies. Four foundational models provide interoperability across PON through their abstract design: Source, Instrument, Music Meta, and Music Representation. These are specialised and extended in the upper levels to add functionalities and contextualise specific domains.

A summary of PON modules is given in Table 1, with links to the repositories storing the modules with documentation, diagrams, and examples. Through our foundational models, PON ontologies can be applied to a wide set of music projects, and the modular design simplifies extensibility and maintenance. To facilitate this process, further documentation and tutorials are also being made available at https://polifonia-project.github.io/ontology-network/. An example of use involving 5 PON modules (besides Core) is shown in Fig. 4.

Table 1. Overview of the modules in the Polifonia Ontology Network. All URIs are also accessible from https://github.com/polifonia-project/ontology-network.
Full size table

4.1 Foundational Models and Their Extensions and Specialisations

The Music Meta module provides a rich and flexible ontology to describe music metadata related to artists, compositions, performances, recordings, broadcasts, and links. Music Meta focuses on provenance and interoperability – essential requirements for the integration of music datasets, which is currently hampered by the specificity of existent ontologies. The model is based on the Information-Realisation ODP [23], allowing to reduce complexity of FRBR-based models, whose application in the music domain has raised concerns [52].

To enable data integration from existing knowledge bases and datasets, we also align Meta to Music Ontology [48], DOREMUS [3], and Wikidata. To facilitate the reuse of Music Meta and its data conversion into OWL/RDF Knowledge Graphs, we developed a library to map arbitrary music metadata into RDF triples. This enables a practical and scalable workflow for data lifting to create Music Knowledge Graphs without expert knowledge of our ontological model.

The Tunes module extends and specialises Music Meta for folk music. The main novelty consists in grouping and describing tunes into “tune families” depending on their melodic similarity (an association requiring rich provenance description of the musicological analysis on the source); which also extends to lyrics families.

CoMeta reuses and extends Music Meta to describe arbitrary music collections, corpora, and datasets. Here, metadata is described at the collection-level (data curator, annotations provided, availability of audio music, etc.), and at the content-level, (e.g., the title, artist, release of each piece in a dataset). The design of CoMeta is informed by a survey of Music Information Retrieval datasets [44].

The Music Representation module provides a comprehensive schema to describe the analysis of musical objects (a score, an audio track, etc.) interpreted according to a theory. Fragments of a musical object (elements of a music object whose temporal location is uniquely identifiable) are described by annotations provided by an agent (e.g. expert annotator, algorithm). An annotation is either the subjective result of an analysis (e.g. a chord played in a specific section) or objective in nature (e.g. a note in a digital score). Each annotation describes some music content (e.g. notes, chords, etc.), which we refer to as a musical projection [42]. Annotations are formalised via our Music Annotation Pattern [5]. whereas the definition of music projections is delegated to the Music Projection module. The generality of the module and its abstraction over the represented content enables the interoperability of different music annotation schemas. The module is aligned to MusicOWL [36], Music Notation Ontology [16], Music Note Ontology [47], and our JAMS ontology (c.f. Sect. 4.2).

The Music Projection module formalises musical entities that can be subject of an annotation. This ranges from traditional musical notation (e.g. note, chords) to informal annotations (e.g. mood, danceability). The module is aligned with MusicOWL, Music Notation Ontology, Music Note Ontology, Music Theory Ontology [49], Chord Ontology [22], and Roman Chord OntologyFootnote 9. This allows to integrate existing domain ontologies. Notably, we also harmonise different chord representations (Chord Ontology, the Roman Chord Ontology and the Tonality Ontology) based on the Unified Model of Chords in Western Harmony [31].

The Instrument Module describes musical instruments as mediums of performance and their technical properties. Given that numerous taxonomies of instruments into groups and families exist (e.g. Hornbostel-Sachs, MIMO, MusicBrainz) and finding common categorisations is an open problem [39], our module provides an abstraction capable to express arbitrary classifications. This is achieved by leveraging the Information-Realisation and the Collection ODPs. Overall, the module allows to: (i) refer to instruments as entities (an instrumentation of a piece for “piano” and “viola”) as well as conceptually (e.g. a viola has 4 strings); (ii) support the integration with different taxonomies and vocabularies, such as [40]; (iii) describe the evolution of instruments in time and space (e.g. a viola as a cultural heritage object being relocated). This provides a foundational level where contributors can “plug” their instrument-specific ontologies [60].

The Bells module extends Instrument to describe bells by means of measurable, intrinsic aspects such as weight, materials, conservation status. The main entities contextualising bells are: (i) the author(s), such as the foundry who built the bell; (ii) the agencies that played some role e.g. the agency that took care of cataloguing the bell; (iii) the place(s) where it has been located; (iv) the tower(s) where the bell has been included; (v) the tools that the set of bells is played with; (vi) documents related to the bells, e.g. bibliographies, protective measures.

The Organs module extends Instrument to describe organs as (i) a musical instrument consisting of parts; and (ii) as a focal point of projects detailing its changes throughout time. To address the former, we used the Parthood pattern from the DOLCE ontologyFootnote 10. The entities of the ODP, Whole and Part make possible the specification of the whole instrument and its parts. In the ontology, the Whole entity refers to the organ instrument, and the Part entity refers to the parts of the organ that are Console, WindSystem, Case, Division, and Action.

The Source module represents various sources of music-related information. These include manuscripts, textbooks, articles, interviews, reviews, comments, memoirs, etc. of different scope and format (physical, digital). The module aims to provide general support to describe information related to the creator and type of the source, the time and place when/where it was created, the context of production and usage, and the subject and goals. Although this conceptualisation leans towards bibliographical sources, the module provides expressivity to indicate multimedia documents (e.g. images of scores, audio recording, video). For example, a video recording of a performance can be considered as a musical source – providing documentary evidence of a composition e.g. during an event.

The Meetups module describes encounters between people in the musical world in Europe from c. 1800 to c. 1945. Historical meetups, which are the main subject of this module, are described by means of four main components: the people involved in the meetup, for instance, the person that is the subject of interest and the people interacting in the event, the place where the encounter took place (e.g., city, country, venue), the type of event, the reason (e.g., music making, personal life, business, among others) and the date when it took place.

The MusicBO module is developed by following a KG-to-ontology process [43]. Ontological axioms, grouped into patterns, are empirically generated from the MusicBO knowledge graph – which is built from a textual corpus on music performances and encounters between music-related agents in Bologna since the 17th century. Such patterns include information about the probability of axioms to happen (as they are derived from the data). For instance, the probability of instances of the pattern compose situation (the process of creating art) to have NaturalPerson as range of the artist property, is higher than the probability of having an Organisation as a composer. In sum, the content of the ontology module is highly dependent on the KG, and the most populated and described entities are: persons, places, organisations, works of art, theatres, and books.

4.2 Modules for Analysis and Annotation of Music

The Music Algorithm module formalises algorithms that can operate on music metadata (using the Meta module), and musical content (via the representation module). The module commitments are similar to those defined by Diamantini et al. in [19]. Indeed, an algorithm is characterised by three main components: a formalisation, which can be theoretical (e.g. pseudocode) or executable (e.g. using a programming language); a parametrisation (e.g. input data); and the kind of task it solves. The latter defines a set of entities that are processed alongside the input and output data requirements and the final goal achieved. The module allows theoretical and quantitative performances to be represented in the context of the algorithm’s parametrisation. Through an abstract and general definition, the formalisation in Music Algorithm can be seen as a general pattern, capable of representing any algorithm regardless of the domain of application. In the context of music, the output of the algorithm is considered an analysis, which is then represented via the Representation module.

The Music Analysis module allows for the analysis of musical pieces using historical and present-day established musical theories: the modal and tonal theories. Through the use of this framework, different subjective analyses can be unified – overcoming the limitations imposed by a “global” theoretical perspective. Different theoretical viewpoints can be used for the interpretation of the same piece. Currently, two historical theories are implemented: Zarlino (1558) and Praetorius (1619) [27, 28]. Through the use of formal reasoning and a comprehensive axiomatisation, the ontology is able to automatically infer the theoretical interpretations of a musical piece and its evolution in time and space.

The Music Annotation module provides different music annotation models to accommodate musicological and information retrieval use cases. The primary objective of this module is to enhance support for other descriptional systems, thus increasing interoperability and conversion possibilities from various music annotation formats. Indeed, all our models are logically interconnected through Music Representation. A fully fledged annotation model here is the JAMS Ontology [7]Footnote 11. This ontology mimics the structure of a JAMS (JSON Annotated Music Specification for Reproducible MIR Research) document [33]. It semantically describes and connects all the elements of the JAMS specification (Annotation, Observation, etc.), including the music metadata and the annotation contents using the Music Meta and Representation modules, respectively.

5 Adoption and Impact

We provide evidence of PON use by Polifonia pilots (Interlink, Tonalities, Meetups, Bells, and MusicBO), which have contributed 6 musical heritage KGs (Sect. 5.1); potential interest of reuse and opportunities for the Semantic Web and Music Technology communities collected from an online survey (Sect. 5.2); early adopters and ongoing synergies from the Polifonia Stakeholder Network for PON validation and annotation of cultural and industrial datasets (Sect. 5.3).

5.1 Current Use by Polifonia Pilots

Interlink :

has released ChoCo and Harmory KGs. Choco [7] provides 20K+ harmonic annotations of scores and tracks, that were integrated from 18 chord datasetsFootnote 12. The KG uses the JAMS ontology in Music Annotation, and the Roman ontology from the Music Projection module. Harmory [6] is a KG of interconnected harmonic patterns derived from ChoCo, and aimed at human-machine creativity (pattern discovery, chord generation, harmonic similarity).

Tonalities KG :

includes dataFootnote 13 from 377 MEI scores and their annotations w.r.t. theoretical concepts (roots, harmonic progressions, dissonant patterns, cadences, etc.), using the 2 theoretical models in the Music Analysis module.

Meetups KG :

describes 74K+ historical meetups from c.1800 to 1945, mentioning 51K+ people from 5K+ places in EuropeFootnote 14. It uses the Meetups ontology and is extracted from 1K artists’ biographies on open-access digital sources.

Bells KG :

describes 88 bells catalogued by the Italian Ministry of CultureFootnote 15. It relies on the Bells module and is part of the ArCo KG – the largest Italian cultural heritage KG from the Italian General Catalogue of Cultural Heritage.

MusicBO KG :

is built via text-to-KG methods [43] on a collection of 137 documentsFootnote 16 on performances and encounters between musicians, composers, and critics happened in Bologna from the 17th century. As mentioned in Sect. 4, the KGFootnote 17 is used as input to the bottom-up modelling of the MusicBO ontology.

Fig. 4.
figure 4

Graffoo [20] example of “Highway Star” by Deep Purple using 5 PON modules to describe: metadata information (Music Meta, bottom), instrument (Organs, bottom-right) and annotation of musical content on two audio recordings via the Music Representation, Projection, and Annotation modules, either related to a studio (top-right) or a live (top-left) performance of the same piece. We remark how the two musical annotations are made interoperable via PON despite their profound differences (JAMS [33] and text, respectively) as they refer to the same fragment.

Full size image
Fig. 5.
figure 5

Selection of questions 4, 6, 7–14 from the online survey, where responses are expressed on a Likert scale ranging from 1 (strongly disagree) to 5 (strongly agree).

Full size image

5.2 Survey of Interest for Future Applications

To gather interest of adoption, we conducted an online survey in which we ask potential adopters 14 questions regarding their background, relevance, and interest in using music ontologies. The survey was conducted via Google Forms, and distributed in the Semantic Web (SW), Music Information Retrieval (MIR), and Digital Humanities mailing lists – gathering a total of \(N = 61\) responses. Among our respondents, 25 work in Semantic Web, 23 in MIR, 26 in Musicology. Most of them have encountered the need for modelling music related data and resources with ontologies (65.6%), focusing primarily on music metadata (45) theory and notation (29), annotations (25) and instruments (28); with 75% doing research or project work related to music data with multiple stakeholders.

Participants were asked to quantify the agreement with statements from 1 (absolutely disagree) to 5 (absolutely agree), 3 being a neutral response (NR; neither agree nor disagree). Results are illustrated in Fig. 5. From questions 6–14 we found that: 49.2% find the reuse of existing music ontologies to be challenging (with 42.6% NR), and the same can be said about the interoperoperability of existing ontologies (57%; 36% NR), their lack of coverage of concepts related to music history and music cultural heritage (57.3%; 32.8% NR); and the lack of large datasets of competency questions for this domain (63%; 34% NR). We also find strong evidence for potential reuse of PON, as participants would be interested in using ontologies for music metadata (78.7%), sources (80.3%), musical instruments (70.5%), and music content (57.4%; 21.3% NR), as well as a CQ dataset for musical heritage (65%; 26.7% NR).

5.3 Adoption by Polifonia Stakeholders

In addition to internal and potential adopters, industrial and institutional stakeholders in the Polifonia Stakeholder Network have also expressed interest to use PON resources. These include the Digital Music Observatory, concerning the use of Music Meta and Source to annotate the numerous music resources of the consortium; and the Université Catholique de Louvain where Anne-Emmanuelle Ceulemans uses the Music Anlysis module for studying the annotation of cadences in Josquin des Prez (composer of High Renaissance music).

We have also planned work with Deezer, Songfacts, and MusicID for the evaluation, extension, and reuse of Music Meta driven by their resources; and collaborations with the EU H2020 MuseITFootnote 18 project to extend the ChoCo KG.

6 Availability, Sustainability, and FAIRness

PON namespaces are introduced in Sect. 4, and permanent URIs were created with the W3C Permanent Identifier Community Group. PON is under version control on public GitHub repositories (c.f. Table 1), and all repositories are also published on Zenodo (with associated DOIs) under the CC-BY 4.0 licence. The storage of all resources on GitHub guarantees their persistence beyond the project, with the University of Bologna and the Italian Ministry of Culture (MiC) committed to host and maintain PON on the long term. We also remark that PON is reused as a sibling ontology project of ArCo by MiC [13].

7 Conclusions

This article addresses the creation of the Polifonia Ontology Network (PON), a collection of expressive ontologies for musical cultural heritage that enable interoperability of existent semantic models for music content and contexts (MusicOWL, Music Notation, Music Ontology, DOREMUS, etc.). Departing from multidisciplinary and domain-expert based requirements in the Polifonia project, we applied and extended the XD methodology for ontology engineering both methodologically (persona/story framework) and technologically (IDEA framework for NLP-assisted co-design). We release 15 new ontologies in PON (v1.0) and the PolifoniaCQ dataset of 361 competency questions under CC-BY 4.0; and provide strong evidence of current and potential reuse by institutional and industrial stakeholders. As next steps, we are planning to perform an extensive CQ-driven evaluation of PON modules; and support our stakeholders and early adopters in the reuse, extension and long term maintenance of our resources.