Home

MILOPA: A Mid-Level Ontology for the Performing Arts

Open Source Handbook

We acknowledge the support of the Canada Council for the Arts.

I. Introduction

Purpose and scope of this handbook.

The performing arts industry is facing an increasing demand to present their offerings in a way that is easily discoverable and understandable to audiences. We see this as audiences continue to flock to digital environments to find and buy cultural products. In order to make information shared in the digital world more useful, it needs to be optimized for different technologies, such as search engines, recommender systems, and computational AI tools that use large language models to process information (such as ChatGPT). However, this can be a challenging task for many artists and arts organizations that may not have the necessary resources or know-how to create and share structured information effectively.

The goal of this handbook is to explore what kind of information software applications are looking to consume (specifically about performing arts events) and to examine how arts organizations might improve sharing this information in digital environments. To do so, the document will explore the popular framework, Schema.org, and look at some of the challenges and opportunities that it presents. The document will also overview a new information representation framework called the Mid Level Ontology for the Performing Arts (MILOPA), which has been developed by the Performing Arts Information Representation Community Group (the PAIR-CG). The MILOPA framework has been created as a core to stimulate discussions about new ways of representing arts and culture information and to create a foundation for future work to build from.

This handbook aims to be a starting place for arts and culture organizations to learn more about adopting tools and techniques for improving their discoverability in a digital context. It's intended to be a resource for any stakeholder in the performing arts, regardless of size or location.

This work is licensed under a Creative Commons Attribution 4.0 International License. This license lets others distribute, remix, adapt, and build upon the work, even commercially with credit to the authors Mariel Marshall, Daniela Rosu with contributions from the Performing Arts Information Representation Community Group.

Existing Representational Frameworks

The best representational frameworks to use for structuring event information are those that are widely supported by search engines and other applications. The most widely used framework for representing event information today is Schema.org, which provides a set of types and properties for describing events, venues, performers, and related information. Schema.org is supported by major search engines, including Bing, Google, Yahoo, and Yandex, as well as by other applications and services that rely on structured data. This means that by using Schema.org markup to structure event information it is possible to improve the visibility and discoverability of events across multiple platforms.

In addition to Schema.org, there are many other frameworks which can be used, including:

The International Committee for Documentation CIDOC-CRM link
Research Data Alliance link
The International Press Telecommunications Council link
The Dublin Core™ Metadata Initiative link
VRA Cor - a data standard for the description of works of visual culture as well as the images that document them. link

These frameworks may not be supported by all applications and services. Schema is the most commonly known representation framework so it has been selected as a focus for this handbook. Additionally, this handbook will discuss MILOPA, the framework newly developed by the PAIR-CG.

Key challenges and limitations of current frameworks

Schema.org is a collaborative community-driven project aimed at providing a standardized vocabulary for describing structured data on the internet. One of the most popular and widely used types of structured data on Schema.org is the event schema. The event schema allows website owners and developers to provide search engines and other applications with detailed information about events, such as concerts, festivals and sports. By using the event schema, website owners can support their event information being displayed accurately and prominently in search results. As a result, they can make it easier for people to find and attend events.

The event schema includes a wide range of properties, including the name of the event, its location, start and end times, ticket prices, performers or speakers, and other relevant details.

While Schema.org is a powerful tool for structuring content, there are several limitations to consider:

Implementation: Schema.org markup must be added to each individual web page, which can be time-consuming for organizations with a large amount of content. Complex event schedules can also be difficult to implement.
Standardization: While Schema.org is widely adopted, there are still inconsistencies in its use across different websites and industries. This can make it difficult for applications to consistently interpret and use the markup.
Limited scope: Schema.org only covers a limited set of information types, which may not be sufficient for some arts organizations' needs.

Some of the scope limitations include:

Discipline Coverage: while Schema.org includes some high level performing arts disciplines, such as music and theatre, it does not have as complete coverage of disciplines such as circus arts, magic, puppetry or performance art. It also doesn't cover subdisciplines. Additionally, the framework is not able to cover the complexities for how disciplines are often combined within a work, in the case of interdisciplinary or transdisciplinary works.
Accessibility Information: Schema.org provides some support for accessibility-related information, but the coverage for performing arts accessibility is not extensive. For example, there are some properties such as “accessibilityFeature” that can be used to describe certain accessibility features of a venue or event. However, there are no specific properties to describe accessibility features that pertain to the performing arts, such as audio descriptions, accessible seating, relaxed performance details and more.
The Artistic Process: Schema.org includes some properties that can be used to describe parts of the artistic process. However, it does not have a specific set of properties or classes dedicated to representing the entire creative or artistic process from ideation to presentation and post-presentation. Additionally, the outputs and outcomes of the artistic process would benefit from additional conceptualization.
Detailed Content Information of performance information: Schema.org provides a way to represent basic information about a performance, such as the performers, location, and time. However, it does not provide a way to represent more detailed information about a performance, such as the movements or sections within a dance or the different acts within a play. This information is particularly important for recommender engines and systems.
Ticketing and pricing information: Schema.org provides some basic properties for representing ticketing and pricing information. However, there is a need for more specific and detailed properties for representing different ticket types, pricing tiers, and discounts.
Collaborators and contributor roles: Performing arts productions often involve a range of collaborators and contributors, such as composers, directors, designers, and technicians. Schema.org currently does not support many of these specific role types.
Representing complex relationships: Performing arts productions often involve complex relationships between multiple entities, such as performers, directors, producers, and venues. Schema.org does not currently provide a way to represent these relationships in a standardized manner, making it difficult to accurately represent the full scope of a creative team on- and offstage.
Historical information: Many performing arts organizations have rich historical data about past productions, performers, critical reviews and venues. Schema.org does not currently provide a standardized way to represent historical data, such as a production's development history. This makes it difficult to integrate this information with current data and provide a comprehensive view of the organization's history or upcoming events.
Creative Rights: Some gaps exist when it comes to representing Creative Rights, particularly around the areas of royalties and licensing. One gap is the absence of specific properties to represent the terms of licensing agreements, such as the duration of the license, the permitted uses of the work, and the royalties or fees paid to the copyright holder. While some of this information can be conveyed using the "offers" and "price" properties, there is no dedicated property for representing the terms of a license agreement. Another gap is the absence of a property to represent the rights of attribution and integrity, which are important components of many Creative Rights regimes. There is also a lack of specific properties to represent the different types of royalties that may be associated with a work.
Representing non-textual data: Performing arts productions often include non-textual data, such as images, audio, and video. While Schema.org provides some support for these types of data, there are still limitations in its coverage, particularly when it comes to representing complex relationships between different types of media.

Overall, while Schema.org provides a useful framework for representing performing arts information, there is still a need for more specific and detailed properties and types to fully capture the nuances and complexities of the performing arts domain. To address gaps and opportunities within existing frameworks, the Performing Arts Information Representation Community Group (PAIR-CG) was formed through the W3C. The group has worked to develop a core information representation framework that represents complex concepts in the performing arts domain, and which provides a mid-level framework for future work to build upon.

Rationale for developing a new representational framework

MILOPA (Mid-Level Ontology for the Performing Arts) is a proposed framework for representing information about live performing arts. The need for such a framework arises from the fact that existing standards and systems are not fully equipped to handle the complexity and diversity of information in the performing arts domain.

MILOPA has been designed to address the specific requirements of the performing arts industry, which often involves the coordination of multiple stakeholders, including artists, producers, venues, and audiences. It aims to provide a framework to capture a wide range of data, including artistic and technical details, historical and cultural context, and audience and marketing information. MILOPA is an open, community-driven framework, which means that it is being developed with input from a range of stakeholders, including artists, producers and researchers. By leveraging the collective expertise and knowledge of these stakeholders, MILOPA aims to create a framework that can act as a robust foundation for future work to build from that is relevant to the needs of the performing arts community.

Overall, the development of MILOPA is motivated by the need to improve the management and accessibility of performing arts content, and to ensure that it can be effectively shared and preserved for future generations and future audiences. By providing a standardized and comprehensive framework for representing performing arts information, MILOPA has the potential to drive innovation and collaboration in the performing arts industry, and to enhance the experience of audiences worldwide.

Overview of MILOPA

The Mid-Level Ontology for the Performing Arts (MILOPA) is developed by the PAIR-CG. MILOPA’s contribution is providing clear, formal definitions for complex concepts and properties. The representational framework is made available using the formal structuring mechanisms of the Ontology Web Language (OWL), which provides an appropriate, Web-compatible approach.

We will sometimes refer to MILOPA as a language for describing performing arts knowledge, reflecting the fact that it provides a standard vocabulary that can be used (together with the other aspects of the OWL) to create descriptions. The MILOPA ontology is an evolving thing that continues to make connections to other development efforts, such as those building ontologies of time, schedules, resources, etc.

The intent of this framework is not to introduce a tool to enforce rigid linguistic constraints in everyday communication in the performing arts. MILOPA is intended, rather, as a framework that can be used to reduce ambiguity in communication and that can be computer-interpretable. It is for this reason that new or modified words have generally been used in the framework to name classes and properties. This was done to reduce the friction around word choice.

For example, in the performing arts, people often use the word “production” with various meanings. It can be a loaded term. Take for example:

Did you see that amazing production of Controlled Damage by Andrea Scott?
What production elements (costumes, set, props) did you like most?

The word production requires disambiguation in these two instances. Rather than using a different word in each case, MILOPA has two different classes that can be used to disambiguate the two meanings. Using MILOPA to achieve this, the two usages could be clarified like so:

Did you see that amazing production [pair-cg: PERFORMANCE_WORK] of Controlled Damage by Andrea Scott?”
What production elements [pair-cg: TANGIBLE_REALIZATION_ELEMENT] did you like most?

The MILOPA ontology is not provided as an extensive resource of terms that can be used for all possible instances. Rather it has been constructed as a selection of core concepts that offer a common foundation upon which future representational efforts can build off. This is why common concepts such as a show’s “door time” or “duration” are not present in this ontology. Instead, this ontology has focused on disambiguating higher level concepts in the domain, such as separating that which is performed from the performance itself. Entire branches, or nodes as they are called in this work, have been indicated for future development.

Additionally, there are many contexts for creating an ontology. This ontology was created specifically for the context of sharing information in the performing arts domain. There are many use cases for the sharing of information, such as promoting a show on a website, archiving a show in a repository, or having a show appear in a search engine query. The intent of MILOPA is to facilitate the management of information, including publishing, storing and retrieval.

A Selection of Key MILOPA Concepts

For full access to the information representation framework including the technical documentation, please visit: https://github.com/pair-cg/milopa.

Here are a few important concepts that have been developed for MILOPA in order to address current gaps and challenges.

Artistic Process

Definition: A type of COMPLEX_ACTIVITY that involves a unique combination of vision, creativity, intuition, inspiration and collaboration balanced with craft, technique, accountability, discipline, and use of time and resources. Cognitive and physical actions are present. The ARTISTIC_PROCESS may include activities such as a DEVELOPMENT_PHASE and one or more REALIZATION_ACTIVITY.

Motivation for inclusion: The arts sector often sees concepts related to “artistic process” within granting systems. For example, the Canada Council for the Arts “concept to realization” grant, which allows artists to apply for funding for activities that occur throughout any phase of the creative continuum. Being able to convey this concept to machines would be helpful for analyzing information not just for funding purposes, but also for research, audience discoverability and more.

Realization Activity

Definition: A type of COMPLEX_ACTIVITY in which a PERFORMANCE_WORK is executed, in whole or in part. Example: Whenever a performer performs, be that in the rehearsal room or on stage for a live audience, they are engaged in a REALIZATION_ACTIVITY. Subclass Examples: REALIZATION_ACTIVITIES can be categorized based on their properties. This can include the agents involved, the context of the activity ( i.e. the circumstances that indicate the completeness, purpose and setting for the REALIZATION_ACTIVITY to occur, such as a rehearsal, workshop performance, or script reading), and also the portion of the PERFORMANCE_WORK being executed (i.e. a first act performance, a single song, a monologue, a full three act play).

Motivation for inclusion: The arts sector often uses the word “performance”when describing the final stage of the artistic process, when audiences are involved. However, throughout a performance’s lifecycle, there may be many different realization activities that occur, from staged readings, workshop performances or even rehearsals. It’s important to be able to distinguish the type of realization activity that is occurring distinct from the thing which is realized (aka the performance_work).

Performance Realization

Definition: The intangible result of a REALIZATION_ACTIVITY being executed, often referred to in the domain as the performance itself. When someone attends a play, or a concert, or musical, they perceive the PERFORMANCE_WORK being executed live before our eyes. This result of this execution is a PERFORMANCE_REALIZATION. For example, an individual may perceive CREATIVE_MATERIAL being performed, such as musicians playing music, actors speaking lines of dialogue, dancers performing movements, acrobats executing acrobatics. AN individual will also perceive TANGIBLE_REALIZATION_ELEMENTs, such as the stage, sets, lights, costumes, props, audience seating, etc.(Doty, 2013); as well as the INTANGIBLE_REALIZATION_ELEMENTs, such as the volume or pitch of an instrument, or the timbre of an actor's voice. Together, these elements make up the PERFORMANCE_WORK. When executed for an audience, the result is a PERFORMANCE_REALIZATION.

Motivation for inclusion: This term is necessary to separate the performance itself (the performance realization) from the thing which is performed (the performance work).

Creative Material

Definition: A component of content relating to or involving ideas generated during the ARTISTIC_PROCESS.
CREATIVE_MATERIAL may include:

Dialogue to be performed
A story to be told
A lighting design to be executed
Music to be performed
Choreography to be performed
Acting states, intentions and beats to be performed

Motivation for inclusion: A performance work is made up of a number of creative and design elements. The arts sector needs some way of talking about these elements in order to conceptualize contributions, creative rights and roles and responsibilities.

Performance Work

Definition: The PERFORMANCE_WORK is the conceptual plan for how elements (such as CREATIVE_MATERIAL) will be executed in front of an audience.

Motivation for inclusion: This term is necessary to separate the performance itself (the performance realization) from the thing which is performed (the performance work).

Conclusion

MILOPA is an initial and timely response to the current information needs of computational tools. However, more work is needed to allow for real adoption and use of the tool. MILOPA is simply a starting place for these conversations to take place. More work is necessary to support and develop the framework and to encourage its adoption alongside more widely used and known efforts such as Schema.org. By adopting existing frameworks while continuing to develop new efforts, arts and culture organizations can make a meaningful contribution to the future of the sector in an ever-changing digital world.

As this undertaking continues, arts organizations and artists are invited to get involved with these efforts, to ask questions and to challenge the possibilities of information sharing and reuse in the domain. To join the PAIR-CG, please visit https://www.w3.org/community/pair-cg/

Contributors

A big thank you to the entire PAIR-CG membership, without whom this work would not have been possible. A special thanks to the Chair of the PAIR-CG Sarah Bay-Cheng, authors Mariel Marshall, Daniela Rosu and contributors Dessa Hayes, Beat Estermann, Frédéric Julien, Daniel Webster.