Performance Event Type: Relationship to other concepts

[fjjulien]

Introduction

The concept of a performing arts performance is represented in several classic RDF ontologies, conceptual models and authority files. This key concept is however not represented in Schema.org. Moreover, there are inconsistencies in the descriptions of specific Schema event types associated with the performing arts domain.

The potential solution is to propose to Schema.org the introduction of a new specific event type (as discussed at PAIR-CG meetings on June 2 and September 1). However, many details need to be discussed with the PAIR-CG community before a formal proposal can be made.

This is issue and the proposed solution are contextualized in this Google Doc.

Specific issue: Relationship to other concepts

1. Should parent-child relationships be defined with other specific Schema event types? If so, can all current Schema specific event types associated with performing genres be considered sub-types to the proposed Performance Event Type? The TheatreEvent type is clearly defined as a performance, so it could be defined as a sub-type. But what about DanceEvent type, which is defined as a social dance?
2. What properties should be associated with this class/type (in Schema and in performing arts ontologies)? schema:Event already includes several properties suited to describing a performing arts performance (audience, maximumAttendeeCapacity, performer, workPerformed, etc.). Do performing arts users have information needs that aren't currently met by Schema properties?
3. What constraints and inference rules could be associated with this class/type (in Schema and in performing arts ontologies)?For example, could this type be inferred when a WorkPerformed property is stated for an event?

[drosu]

Hi @fjjulien,

1. I think that contributing a effective formal definition for "performance", "performing arts work" would be one of the major contributions that PAIR-CG can make. In my opinion, it is premature to discuss mappings to existing schemas before the group has definitions for these terms that are correct and complete with respect to the set of representational requirements that the group is working on eliciting and refining (the collection of the user stories is the first step in the process of representational requirements elicitation / engineering). The process of defining mappings to existing schemas, such as Schema.org is far from trivial as (1) the existing frameworks / ontologies abide by ontological assumptions that are often tacit and not clearly stated and (1) in some cases the definitions provided in the existing schemas are circular and / or contain other logical fallacies. Directly importing or making mapping commitments to ontologies that are logically inconsistent would render a formal ontology also logically inconsistent and useless as a foundational representational framework that can be used by software applications.
2. This is a great question that the domain experts in the group can start discussing as part of the representational requirements eliciting process.

3.1 The inference rules are provided by the logic we decide to abide by, e.g., First Order Logic, Description Logic, Default Logic, etc. The logic we decide to abide by, e.g., Description Logic if we choose to formalize our ontology in OWL, will also provide a framework for formalizing the constraints we decide to add in addition to those implicitly provided by the formalism of choice as sub-classing, class instantiation, etc.
3.2. The semantics of the constraints, e.g., whether a performance can be associated with only one venue or with multiple venues, will have to be decided by the group and discussions around these issues can start / continue, as they as part of the requirements elicitation / engineering process. Once constraints are described in natural language the technical team can start formalizing them check whether they give raise to any logical inconsistencies.
I hope this helps. I'd be happy to provide clarifications and continue the discussion.
Daniela

[fjjulien]

The following comments were shared by @mariel-marshall in Issue109: #109 (comment). Since they relate to this issue, I am copying them here:

1. Would a "performing arts performance" as you are proposing be on the same hierarchical level as the other more specific types of events already existing in Schema, such as: BusinessEvent, ChildrensEvent, ComedyEvent, ...
2. Or are you proposing that "performing arts performance" would be a parent category for more specific types. And that things like MusicEvent, TheaterEvent or ComedyEvent would need to be adjusted to be children of it?
3. If I am attempting to markup Cafe Sarajevo, as an interdisciplinary performance experience across theatre, dance, music and VR, how would you imagine it could be marked up using schema.org? Perhaps using specific examples could help.
4. the current model has a hierarchical structure of types which doesn't easily allow for multi type classification, which seems to be a real challenge here.

@drosu what would your suggestion be for addressing these challenges?

There is an "additionalType" to markup an item with multiple types

[fjjulien]

@mariel-marshall

1. Schema has only two hierarchical levels for event types: the generic shema:Event is the parent type, and all specific event types a children types. The only possible level for a performing arts performance type is the specific event types.
2. Even if Schema allowed a 3-level hierarchy, I would personally not set the performing arts performance type as a parent to other more specific types. Firstly, the specific types in Schema are poorly defined, so there are risks they may be used to describe non-performance events. schema:danceEvent is particularly problematic, because it is defined as a "social dance". Secondly, rather than creating a taxonomy events according to their genre, we could simply model the genre as a distinct property for performing arts performance event (i.e., rather than create one event type for each genre, have a single event type and provide the genre information within a triple, for example: "performanceEvent - hasGenre - theatre"). Genre are complex enough on their own. Several models have represented disciplines and genres as a two-level taxonomy. Duplicating such a taxonomy over the event taxonomy would be redundant, unduly complex and would require maintenance to keep the event taxonomy in synch with the genre taxonomy.
3. I'm not sure how to deal with interdisciplinary events.
4. If genre is represented as a distinct property, then we could - and should - enable multiple genre values.

[fjjulien]

rather than creating a taxonomy events according to their genre, we could simply model the genre as a distinct property for performing arts performance event.

Actually, the proper domain (i.e. the term "domain" designates the class which is the subject for a given property) for the "genre" property should not be the event itself. "Genre" should rather be a property of the performing arts work (which is performed during the event). That's how we modelled it in the LDFI Conceptual Model (the domain is frbr:Endeavour). Schema takes a similar modelling approach: schema:genre is defined as "Genre of the creative work, broadcast channel or group" and it can be used as a property on any of these three types.