1 Introduction

The conservation of cultural heritage is very important for humankind. Today, many cultural organizations and actors store and maintain cultural data in digital forms. Applications like virtual visit of museums and culture search portal have been developed to provide digital experiences and interactions with cultural data.

Semantic Web technologies have been used in the cultural heritage field since more than a decade. An important amount of semantic data models, vocabularies and knowledge graphs (KG) have flourished. On the data model and vocabularies side, we can mention CIDOC Conceptual Reference Model [3], Cultural-ON [8], Sampo [6] and the Getty vocabulariesFootnote 1. With its own data model [7], Europeana tries to facilitate the discoverability of cultural resources by collecting the resources’metadata and by centralizing them [5].

On the knowledge graph side, the Amsterdam Museum’s Linked Open Data comprises the entire collection of the Amsterdam Museum consisting of more than 70,000 object descriptions [2]. ArCoFootnote 2 is a knowledge graph containing around 800.000 catalogue records of Italian cultural heritage entities (ex. archeological objects, numismatic objects). In the music domain which concerns more directly our work, we can mention the LinkedBrainzFootnote 3 project that helps MusicBrainz (an open music encyclopedia that collects music metadata) publish its database as Linked Data. Last, the DOREMUS knowledge graph [1] describes classical music works and their associated events (e.g. performances in concerts). The data come from three major French cultural institutions: the French National Library, Radio France and the Philharmonie de Paris.

In this paper, we introduce MusicKG, a unique cultural heritage knowledge graph containing representations of sound and music in the Middle Ages. In Sect. 2, we describe the source data of MusicKG. In Sect. 3, we detail the ontology underlying MusicKG. In Sect. 4, we show how MusicKG is connected to the Linked Open Data cloud. In Sect. 5, we illustrate the data scope of MusicKG with several SPARQL query examples. Section 6 discusses the potential impact of MusicKG on the research in medieval musicology and concludes the paper.

2 Source Data

The data in MusicKG comes from Musiconis, a database of musical iconographies created from several partner databasesFootnote 4: Musicastallis, Vitrail, Metropolitan Museum (NY), Mandragore, Initiale, Sculpture, Gothic Ivories, Et Stalla, and Romane. Each of the partner databases has its own specificity, generally related to the material support of its representations. For example, the Musicastallis database catalogs musical iconographic representations presented on the carved choir stalls of religious buildings. Currently, the Musiconis database contains 2154 iconographic representations whose scenes not only contain musical but also vocal, acrobatic or choreographic performances. These scenes are deeply analyzed and each instrument is described with organological details. Figure 1 depicts a Musiconis illumination representing King David tuning his harp. In this illumination of the character “B”, it is possible to observe many details: the number of strings, the tuning key, the characteristics and the detailed form of the instrument.

Fig. 1.
figure 1

King David tuning his harp - http://musiconis.huma-num.fr/en/fiche/39/x.html

Full size image

3 MusicKG Data Model

We follow the W3C recommendation about “Data on the web best practices” [4]. We reuse vocabularies and resources as much as possible, including Wikidata from which the P… and Q… items listed below are taken from. In this section, we present the MusicKG data model which depicts representations of sound and music in the Middle Ages. The main class of our model is Visual artwork (Q4502142) (herein “artwork”) which represents a visual artistic work or creation (see Fig. 2). Each Visual artwork instance (see example in Fig. 3) is connected to the original sources through several predicates: official website (P856), collection (P195), inventory number (P217) and described at URL (P973). Also, each artwork instance has a title from the Musiconis database and a title from its original database described by title (P1476) and stated as (P1932) respectively.

Fig. 2.
figure 2

The Visual artwork entity with its corresponding relations in our KG

Full size image
Fig. 3.
figure 3

Representation of the artwork instance describing the example of Fig. 1.

Full size image

Images are essential for iconographic data. Generally, several images (P18) are associated with an artwork to capture all the details from different angles and with different resolutions. Regarding dates, each artwork has three different properties: start time (P580); end time (P582) and time period (P2348) that indicate the century, the date on which the artist began and finished creating the artwork respectively.

The class Visual artist (Q3391743) refers to the artist who made the artwork. An artwork is associated to its creator with the relation creator (P170). Each artist entity is portrayed with the properties birth name (P1477) and notable work (P800). In addition, we added two relations to each artwork instance: material used (P186) and fabrication method (P2079). In one hand, the relation material used describes the material an artwork is made of. This relation associates instances of artwork with Art materials (Q15303351) such as Wood (Q287) or Ivory (Q82001) for sculptures; Textile (Q28823) for embroideries and tapestry weavings; or Glass (Q11469) for stained glasses. On the other hand, the relation fabrication method relates an artwork with its Artistic technique (Q11177771), such as Sculpture technique (Q21711025) or Painting technique (Q1231896). In many cases, we have the information about the manuscript (Q87167) or the Architectural element (Q391414) to which a certain artwork belongs to. Examples of architectural elements are archivolts (Q636008), misericords (Q1938805), among many others. In those cases, we relate both entities through the relation part of (P361).

4 Linking MusicKG to the Linked Open Data Cloud

The singularity of MusicKG is its analysis of performances and the relationships between performances. This is one of the main contributions of our Knowledge Graph since, as far as we know, there are no other works that describe to this level of detail the relationships between entities within iconographic representations. Moreover, our model has been enriched with additional information coming from other popular Knowledge Graphs: Wikidata, Getty Vocabularies, Iconclass, MIMO and Geonames. Figure 4 shows an example of the interconnections between MusicKG and the aforementioned Knowledge Graphs.

Fig. 4.
figure 4

Example of links between MusicKG and external KGs on the LOD cloud

Full size image

We used the Wikidata entity Q35140 to represent performances. All performances are related to one or several performers (Q16010345) through the relation performer (P175) and practiced by (P3095) respectively. In our KG there are instrumental, vocal, choreographic and acrobatic performances. In the case of instrumental performances, the relation instrument (P1303) is used to associate a performance with the instrument (Q3095) played.

The property occupation (P106) establishes a relationship between a performer and a profession (Q35140) that represents their occupation or the activity they perform in the artwork. Some of the sixteenth century professions represented in our Knowledge Graph are: acrobat, singer, dancer, animal trainer, conjurer, juggler, pedagogue or partition holder. In addition, a performer may be an instance of (P31) an animal (Q729), adult (QQ9584157) or mythical entity (Q24334685); or have a sex or gender (P21) such as male (Q6581097) or female (Q6581072).

5 SPARQL Query Examples

MusicKG can be accessed by three means: a downloadable data dump, a Virtuoso faceted browser and a public SPARQL endpoint. All the information and links are available onlineFootnote 5. MusicKG is oriented towards visual artworks, performances, performers and instruments. Users can specify techniques, materials, historical periods, etc. To illustrate the data we may retrieve from MusicKG, in Table 1, we provide two representative examples with their associated SPARQL query and result.

Table 1. Representative competency questions, SPARQL queries and results
Full size table

6 Conclusion and Future Work

In this paper, we presented MusicKG, a multilingual cultural heritage knowledge graph containing representations of sound and music in the Middle Ages. We presented respectively the source data, the ontology data model, how it is connected to external sources in the Linked Open Data Cloud and representative SPARQL queries. MusicKG may have a great impact on the research in medieval musicology, and more particularly, in musical iconography. The SPARQL endpoint allows to make more precise queries and to retrieve more accurate results. Furthermore, the connection with the LOD cloud may bring several benefits that we envisage exploiting. Wikidata items have known multilingual labels and aliases. We plan to retrieve these data more exhaustively to enable the multilingual display of the knowledge graph. We consider making the MusicKG searchable in multiple languages so that more people can access easily this unique cultural heritage database. As Wikidata is becoming the central hub for cultural heritage datasets with lots of institutions publishing their catalogue data, we will study the ingestion of MusicKG into Wikidata.