This website uses cookies to ensure you get the best experience. By clicking or navigating the site you agree to allow our collection of information through cookies. More info

Posted on Friday September 1, 2017

Updated on Monday November 6, 2023

Representing performing arts metadata in EDM

The Specialised Information Service Performing Arts project aggregates metadata from the performing arts domain and presents them in a VuFind-based search portal as linked open data. The project was funded by the German Research Foundation and ran at the University Library Frankfurt am Main from January 2015 to December 2017.

The project aggregated metadata describing performance-related objects from libraries, archives and museums in Germany, Austria and Switzerland. Due to the diversity of data providers and data acquisition workflows, the metadata turned out to be very heterogeneous and domain specific. In order to equally handle and display the metadata and make it available as Linked Open Data, it had to be represented into one aggregation model (Fig. 1). Hence, an interoperable and flexible metadata standard was needed to meet metadata requirements from the domain.

The additional step of mapping all metadata to a common framework was also crucial to enable smaller cultural heritage institutions from the performing arts domain to have their metadata displayed in the performing arts portal and available as Linked Data.

Fig. 1 Aggregation model : The provided heterogeneous metadata is mapped from its original model to EDM. The resulting metadata is indexed into SOLR, enriched and displayed via VuFind.

Metadata in the performing arts domain present a lot of challenges: different cultural heritage objects are at stake such as the performance itself but also printed books, manuscripts, photographs and videos documenting it or being an adaptation of it. In addition, performing arts metadata are rich in information about people, places and events that are crucial to understand the domain.

Re-using the Europeana Data Model (EDM) proved to be the right choice as the model is transcending domain-specific metadata standards. Based on a Semantic Web framework, it can be extended without hindering data interoperability. In using Linked Data technology, EDM provides the basis to model relations between cultural heritage objects and between contextual resources and therefore enabling a richer user experience.

EDM has been already re-used in several digitisation projects, each having produced a comprehensive collection of mappings, applications profiles or extensions. The project decided to re-use the DM2E and ECLAP extensions to address its requirements.

A specific application profile

Due to the nature of the metadata, the project had to create a new set of guidelines[1]applicable to existing EDM classes and properties.

EDM requires each Provided Cultural Heritage object (edm: ProvidedCHO) to have at least one digital representation (edm:WebResource). Since the main focus of the project is on retrieval of the metadata records, the necessity to provide at least one of edm:isShownAt or edm:isShownBy in ore:Aggregation was alleviated. If a link to a viewer, or a link to the metadata of the object in the providers' catalogue are not available, records without a digital representation are displayed with a generic thumbnail and without a link. In addition, a link to the homepage of the data provider is always available so that the user can contact the data provider to get more information.

The project also created an extension to EDM as the current specifications were not covering all the needs.

The DM2E extension of EDM was re-used to describe more granular metadata for cultural heritage objects with properties like dm2e:subtitle, dm2e:callNumber.

"" a edm:ProvidedCHO ;
dc:description "Klassifikation: 01. Sprechtheater"@de ;
dc:language "de";
dc:title "Leonce und Lena / Georg Büchner"@de ;
dc:type "Archivmaterial" ; dc:subject "Sprechtheater" ;
dcterms:isPartOf "" ;
dcterms:spatial "" ;
dcterms:spatial "" ;
dcterms:temporal "28. Mai 1998" ;
dm2e:levelOfHierarchy "1" ;
dm2e:callNumber "Dokfonds-Theater 16579" .

Fig. 2 Representation of a collection using the DM2E namespace.

The project also used it to represent data for Agents. As specified in the DM2E extension, a distinction is made between metadata describing a person (use of the class foaf:Person) and an Organization (foaf:Organization). The more general class edm:Agent is used when it is unknown whether the Agent is a person or an organization. Fine-grained properties are also used to further describe a person. For instance DM2E re-uses PRO [2], a SPAR vocabulary to describe Agent roles. The project used properties such as pro:author and pro:translator for manuscript data like prompt books and libretti.

EDM was also further extended with the ECLAP namespace covering the specific properties for the performing arts domain like the place and type of a performance, eclap:performancePlace and eclap:performingArtType. With properties such as eclap:actor, eclap:dancer and eclap:setDesigner, ECLAP can also reflect the different roles of contributors in the creation of or the performance itself (See data example in Fig.3 below).

<> a edm:ProvidedCHO ;
pro:author "" ;
eclap:director ""
eclap:setDesigner "" ;
eclap:costumeDesigner "” ;
dc:description "Prinz Leonce, der Sohn König Peters vom Reiche Popo, ist seines Lebens überdrüssig, das ihm keinen Anlaß zu sinnvoller Betätigung bietet(..)@de ;
dc:identifier "", "TMIN_1911-1912 Düsseldorf", "32238" ;
dc:title "Leonce und Lena"@de ;
dc:language "de" ;
dc:type "" ;
dcterms:created "”;
edm:isRelatedTo "";
dcterms:provenance "Theatermuseum der Landeshauptstadt Düsseldorf, Düsseldorf" ;
eclap:performancePlace "Schauspielhaus Düsseldorf Dumont-Lindemann" .

Fig. 3 Representation of a performance using the ECLAP and PRO namespaces.

The project also re-uses properties from the BIBO and GND ontologies. Refer to for the full specifications (Disclaimer: the work on this documentation is still ongoing)

The use of edm:Event

One issue encountered by the project has been the mixing of information related to a particular performance with information about related cultural objects such as a photograph or a play. As shown in Fig. 4 one way to solve this issue has been to represent the performance and the cultural object(s) related to it as two separate edm:ProvidedCHO linked together with the property edm:isRelatedTo (see data example in Fig.2)

Fig. 4 Data representation of two ProvidedCHOs: one representing a photograph ( and one for the performance ( .

We were therefore particularly interested in modelling theatre or dance performances as edm:Event instead of objects (edm:ProvidedCHO). For instance for a given theatre play, such a modeling enables us to describe information such as the creation of the manuscript, the publication of the print edition, the play’s premiere performance, other performances, or a screen adaptation. Fig. 5 shows how specific cultural heritage objects such as a play or a photograph represented as edm:ProvidedCHO are linked to a particular edm:Event class instance using the property edm:wasPresentAt.

Fig. 5 Example using edm:Event to represent performances.

The Event modeling allowed us to provide an accurate description of the relationships between cultural heritage objects and the specific Event they were present at.

However we could not achieve an ideal mapping. First of all, we experienced difficulties in modeling the provided data as an Event because of its granularity. Most of the aggregated metadata either focuses on cultural object descriptions and therefore does not have the granularity required to model Event data, or on the different aspects of an Event which complicated a homogeneous modeling. As mentioned earlier, in some cases information about a specific performance Event and information about the Provided Cultural Heritage object is still mixed within the same metadata description. Further work will be undertaken to create more performance Events from these metadata descriptions.

Secondly, we had difficulties representing the contribution of a specific Person to the performance Event using the current EDM specifications as shown in Fig. 5. We could indicate that a person was present at the event but could not express what kind of contribution a person made to a performance like the role of the director of the play, the choreographer, or the set designer. Therefore, the model needs to be developed so that it allows for properties more specific than the general edm:wasPresentAt that describe the role of a contributing person like eclap:setDesigner or eclap:choreographer in a specific Event. At the time of writing, the refinement of the Event modeling is still ongoing. We are discussing the possibility of using the crm:P11_had_participant property or subproperties in edm:Event. We will, however, need as many properties as roles as it is currently the case re-using the ECLAP properties.

For further technical insights, the ideas and solutions implemented in the Specialised Information Service Performing Arts are explained in more detail in Beck, J., Büchner, M., Bartholmei, S., Knepper, M. Datenbank Spektrum (2017). doi:10.1007/s13222-016-0241-6

[1]The full set of guidelines is currently being documented at